You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2015/04/20 16:40:13 UTC
Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a
Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the
NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
fix it)?
I could work around the above by setting "udp_preference_limit = 1".
However, I then run into an issue where it fails due to no
pre-authentication data in the request. Are we sure that this parsing is
working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks Kiran for the points!
>> These tests can surely be migrated to Kerby.
Great!
>> it would be nice if Kerby's KDC can be launched with annotations just like the way @KdcServer
It’s interesting.
Regards,
Kai
From: Kiran Ayyagari [mailto:kayyagari@apache.org]
Sent: Tuesday, April 21, 2015 6:21 AM
To: Apache Directory Developers List; Colm O hEigeartaigh
Subject: Re: Kerby GSS tests?
On Mon, Apr 20, 2015 at 10:40 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
there are few GSS tests in ApacheDS, but they are all testing the Kerberos server part of ApacheDS.
These tests can surely be migrated to Kerby.
And otoh, it would be nice if Kerby's KDC can be launched with annotations just like the way @KdcServer
does in ApacheDS.
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
Re: Kerby GSS tests?
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Apr 20, 2015 at 10:40 PM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> Hi all,
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> there are few GSS tests in ApacheDS, but they are all testing the Kerberos
server part of ApacheDS.
These tests can surely be migrated to Kerby.
And otoh, it would be nice if Kerby's KDC can be launched with annotations
just like the way @KdcServer
does in ApacheDS.
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Kiran Ayyagari
http://keydap.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
From your logs looks like you’re not using Kerby client API to contact with Kerby KDC. So I guess your client didn’t send preauth data, but Kerby KDC required it by default, then it refused. Please note it’s still on-going to implement kdc server correctly handling krb errors and the 4 passes. When done, your client will be responded with error message in such case, instead of nothing got until timeout. If it’s desired, I will raise the priority of the task in my side.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, April 21, 2015 6:29 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Li, Jiajia" <ji...@intel.com>.
I’d like to follow this issue.
Thanks
Jiajia
From: Kiran Ayyagari [mailto:kayyagari@apache.org]
Sent: Tuesday, April 21, 2015 9:40 PM
To: Apache Directory Developers List; Colm O hEigeartaigh
Subject: Re: Kerby GSS tests?
On Tue, Apr 21, 2015 at 8:52 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
yes, it is in KerberosUtils[1] see the cipherAlgoMap and the orderEtypesByStrength() method
[1] http://svn.apache.org/repos/asf/directory/apacheds/trunk/kerberos-codec/src/main/java/org/apache/directory/shared/kerberos/KerberosUtils.java
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
Re: Kerby GSS tests?
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Apr 21, 2015 at 8:52 PM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
yes, it is in KerberosUtils[1] see the cipherAlgoMap and the
orderEtypesByStrength() method
[1]
http://svn.apache.org/repos/asf/directory/apacheds/trunk/kerberos-codec/src/main/java/org/apache/directory/shared/kerberos/KerberosUtils.java
>
> Colm.
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>>
>>
>> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>>
>>> Hi Colm,
>>>
>>>
>>>
>>> Yes it’s a great fix! May be we could also update our related kdc test
>>> to repeat the issue and guard the fix? In our existing tests, the enctypes
>>> used in KrbClient are the same with the ones in KdcServer side, so we don’t
>>> find the issue until now. Yes, client may very likely request different
>>> enctypes that the KdcServer doesn’t support/enable yet.
>>>
>>>
>>>
>> yes, clients can send different enctypes depending the platform they are
>> running on.
>>
>> The enctypes should always be sorted from the most to least
>> strong/preferred on the server side
>> and then pick the best from the ones requested by the client.
>>
>> Thanks again.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kai
>>>
>>>
>>>
>>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> *Sent:* Tuesday, April 21, 2015 7:33 PM
>>>
>>> *To:* Apache Directory Developers List
>>> *Subject:* Re: Kerby GSS tests?
>>>
>>>
>>>
>>> Hi Kai,
>>>
>>> I've found another bug. We are just picking the first desired encryption
>>> type in KdcRequest.checkClient(). However, we may not actually have this
>>> key. This leads to an NPE. Example:
>>>
>>> We are requesting:
>>>
>>> aes256-cts-hmac-sha1-96 18
>>> aes128-cts-hmac-sha1-96 17
>>> des3-cbc-sha1 16
>>> arcfour-hmac 23
>>> des-cbc-crc 1
>>> des-cbc-md5 3
>>>
>>> We pick the first one...however we only have the following keys stored:
>>>
>>> des3-cbc-sha1 16
>>> aes128-cts-hmac-sha1-96 17
>>>
>>> What do you think of this patch?
>>>
>>> diff --git
>>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
>>> index 2165e17..e6bcef0 100644
>>> ---
>>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>>> +++
>>> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>>> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
>>> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
>>> setClientEntry(clientEntry);
>>>
>>> - EncryptionType encType =
>>> request.getReqBody().getEtypes().listIterator(
>>> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
>>> - setClientKey(clientKey);
>>> + for (EncryptionType encType : request.getReqBody().getEtypes())
>>> {
>>> + if (clientEntry.getKeys().containsKey(encType)) {
>>> + EncryptionKey clientKey =
>>> clientEntry.getKeys().get(encType);
>>> + setClientKey(clientKey);
>>> + break;
>>> + }
>>> + }
>>> }
>>>
>>> protected void preauth() throws KrbException {
>>>
>>> Colm.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
>>> coheigea@apache.org> wrote:
>>>
>>>
>>>
>>> Yep I will do!
>>>
>>> Colm.
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>
>>> wrote:
>>>
>>> Yes, it looks like a good fix, 0 is there instead of null, for time
>>> fields in kdc request. Would you double check other time values by the way?
>>> Thanks!
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kai
>>>
>>>
>>>
>>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> *Sent:* Tuesday, April 21, 2015 7:11 PM
>>>
>>>
>>> *To:* Apache Directory Developers List
>>> *Subject:* Re: Kerby GSS tests?
>>>
>>>
>>>
>>>
>>>
>>> The problem above is that the "end time" is 0 instead of "null". What do
>>> you think of this patch?
>>>
>>> diff --git
>>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
>>> index 3d49af3..23275fc 100644
>>> ---
>>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>>> +++
>>> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>>> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
>>> }
>>>
>>> KerberosTime krbEndTime = request.getReqBody().getTill();
>>> - if (krbEndTime == null) {
>>> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
>>> krbEndTime =
>>> krbStartTime.extend(config.getMaximumTicketLifetime()
>>> } else if (krbStartTime.greaterThan(krbEndTime)) {
>>> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>>>
>>> Colm.
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
>>> coheigea@apache.org> wrote:
>>>
>>> Hi Kai,
>>>
>>> 2. Please disable preauth in KDC side or require preauth in client
>>> side. Looks like client didn’t send preauth data but KDC required it.
>>>
>>>
>>>
>>> Ok I got a bit further by doing this. However, from what I can find out,
>>> the GSS client code should be sending the Pre authentication data (and
>>> there appears to be no option to disable it). So I think there may be a bug
>>> in how Kerby is processing the header? Should we log a JIRA to track this?
>>>
>>> The error I now get (when disabling pre auth in Kerby) is:
>>>
>>> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
>>> later than end time
>>> at
>>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>>> at
>>> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>>>
>>> Any ideas? The Kerby server + CXF client are both on the same machine...
>>>
>>> Colm.
>>>
>>>
>>>
>>>
>>>
>>> If you don’t want to trouble with the config stuff, please just change
>>> the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kai
>>>
>>>
>>>
>>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> *Sent:* Tuesday, April 21, 2015 6:34 PM
>>> *To:* Apache Directory Developers List
>>> *Subject:* Re: Kerby GSS tests?
>>>
>>>
>>>
>>> Actually I spoke too soon, I do know how to reproduce the
>>> "pre-authentication" error. Simply uncomment the line
>>> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
>>> put a printStackTrace in the NettyKdcServerImpl, I see:
>>>
>>> Error occured while processing request:Generic error (description in
>>> e-text)
>>> SocketTimeOutException with attempt: 2
>>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
>>> #bytes=169
>>> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
>>> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70,
>>> /127.0.0.1:43973 => /127.0.0.1:9002]
>>> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
>>> (description in e-text)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>>>
>>> Colm.
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
>>> coheigea@apache.org> wrote:
>>>
>>> Hi Kai,
>>>
>>> Thanks for your response. I have a test-case of sorts that shows the
>>> interop failure (although I can't reproduce the issue I reported yesterday
>>> about the preauthentication data).
>>>
>>>
>>> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>>>
>>> Run it with "mvn clean install". You may need the install the parent
>>> module as well before running this, which is one level up.
>>>
>>> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
>>> client API to successfully communicate with it. Then I have a Apache
>>> CXF-based test which uses the Kerberos functionality here (based on GSS) to
>>> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
>>> output looks like:
>>>
>>> Loaded from Java config
>>> >>> KdcAccessibility: reset
>>> >>> KdcAccessibility: reset
>>> Using builtin default etypes for default_tkt_enctypes
>>> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> >>> KrbAsReq creating message
>>> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
>>> retries =3, #bytes=169
>>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
>>> #bytes=169
>>> java.net.SocketTimeoutException: Read timed out
>>> at java.net.SocketInputStream.socketRead0(Native Method)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:210)
>>> at java.io.DataInputStream.readInt(DataInputStream.java:387)
>>> at
>>> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
>>> at
>>> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> at java.lang.Thread.run(Thread.java:745)
>>> >>>DEBUG: TCPClient could not read length field
>>> >>> KrbKdcReq send: #bytes read=0
>>>
>>> Any ideas?
>>>
>>> Colm.
>>>
>>>
>>>
>>> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>
>>> wrote:
>>>
>>> Hi Colm,
>>>
>>>
>>>
>>> We haven’t any test for GSS client against Kerby yet, though we do have
>>> tests in protocol level for ApReq (in kerb-core-test module). We might look
>>> at existing ApacheDS Kerberos codes to see if any such end to end tests to
>>> port.
>>>
>>>
>>>
>>> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
>>> to be done yet. I originally got them done some days ago, but recently I
>>> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
>>> would be good to record them.
>>>
>>>
>>>
>>> For the issue you ran into, do you have test codes to repeat it, so we
>>> may have the chance to look at it? Thanks.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kai
>>>
>>>
>>>
>>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> *Sent:* Monday, April 20, 2015 10:40 PM
>>> *To:* Apache Directory Developers List
>>> *Subject:* Kerby GSS tests?
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> Are there any tests in the source (or has anyone successfully tested) a
>>> Java GSS client -> Apache Kerby?
>>>
>>> The first issue I ran into was that neither the KdcNetwork nor the
>>> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
>>> fix it)?
>>>
>>> I could work around the above by setting "udp_preference_limit = 1".
>>> However, I then run into an issue where it fails due to no
>>> pre-authentication data in the request. Are we sure that this parsing is
>>> working correctly?
>>>
>>> Colm.
>>>
>>>
>>>
>>> --
>>>
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>>
>>
>> --
>> Kiran Ayyagari
>> http://keydap.com
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Kiran Ayyagari
http://keydap.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Good to this point. I’m looking at it and will respond a little later. Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
The just fix was in the thinking that, when issuing a service ticket, it should use the client principal from the tgt because of security, other than from the KdcReq body. Frankly speaking, the codes haven’t got the chance to be tested till now.
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, April 23, 2015 7:25 PM
To: Apache Directory Developers List; coheigea@apache.org
Subject: RE: Kerby GSS tests?
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Li, Jiajia" <ji...@intel.com>.
Hi, Colm,
I Fail to run GSSInteropTest, the detail in
https://issues.apache.org/jira/browse/DIRKRB-246
Do you have any idea to fix it?
Thanks
Jiajia
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 29, 2015 9:30 PM
To: kerby@directory.apache.org; coheigea@apache.org
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Will we also be supporting it for the Default case as opposed to the Netty case?
Sure, we will.
>> there is no validation of the service ticket. I will add this in
That's great. And also, based on this work, it would be possible to have another one in the SASL framework.
Regards,
Kai
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 29, 2015 8:50 PM
To: Zheng, Kai
Cc: kerby@directory.apache.org; Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Cool, I'll try out the UDP support. Will we also be supporting it for the Default case as opposed to the Netty case?
I'm not really sure if my test-case qualifies as an end-to-end test...there is no validation of the service ticket. I will add this in...
Colm.
On Wed, Apr 29, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Thanks Colm for the great work!
>
> Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
>
> By the way, Yaning made the UDP support happen for the NettyKdcNetwork
> today,
> https://issues.apache.org/jira/browse/DIRKRB-231
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 29, 2015 6:38 PM
> To: kerby@directory.apache.org
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Ok done!
>
> Repository: directory-kerby
> Updated Branches:
> refs/heads/master e452f1854 -> eb2e4c1ae
>
>
> Adding a GSS unit test
>
>
> Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
> Tree:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
> Diff:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
>
> Colm.
>
> On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> > Colm,
> >
> > Yes it’s a known issue due to incomplete implementation. When the
> > following one is resolved, I thought we could get back to this
> > verifying the function. I will hopefully work on it recently.
> > https://issues.apache.org/jira/browse/DIRKRB-235
> >
> > By the way, is it doable to port your end to end tests into Kerby,
> > without introducing the many deps? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, April 27, 2015 6:46 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Thanks, everything is working now :-) The remaining issue is that
> > the tests are failing when pre-auth is enabled. Do you want me to
> > start looking into this, or are there known issues here?
> > Colm.
> >
> > On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > It’s done now. The root cause is due to the incorrect TGS principal
> > construction. Please check out latest codes and also apply the
> > following change to your test project.
> >
> > Regards,
> > Kai
> >
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> > @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> > }
> >
> > @org.junit.Test
> > - @org.junit.Ignore
> > + //@org.junit.Ignore<ma...@org.junit.Ignore>
> > public void unitTest() throws Exception {
> > KrbClient client = new KrbClient();
> >
> > diff --git
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > b/apache/cxf/cxf-k
> > index 3806a70..802baa0 100644
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Friday, April 24, 2015 8:12 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > So it’s another issue existing in client side, right? I checked our
> > today’s changes and found nothing related to the issue. It may be
> > not caused by the fix of previous issue.
> >
> > I can’t debug on your project due to maven module deps. I saw no
> > much difference from your test case with Kerby’s, but wonder why
> > it’s ok in Kerby project.
> > Will continue to investigate it tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, April 24, 2015 5:52 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Excellent thanks! However, now the unit test using the Kerby client
> > API fails :-) The problem is in getting the TGT. Using the GSS
> > client API, the value for the "PrincipalName principal =
> > request.getReqBody().getSname();" in
> > KdcRequest.checkServer() is:
> >
> > krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> > However, using the Kerby client API it's:
> >
> > krbtgt
> > and hence an error is thrown, as this principal is not stored. Any
> > ideas here? You can reproduce just by updating my github project,
> > and removing the @Ignore annotation from the "unitTest".
> > Colm.
> >
> > On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > It’s done! Below is my test running your test project. Please check
> > latest codes and verify it, thanks!
> >
> > >>>DEBUG: TCPClient reading 594 bytes KrbKdcReq send: #bytes
> > >>>read=594
> > >>> KdcAccessibility: remove localhost:9002
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> > http://service.ws.apache.org>
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > Using builtin default etypes for permitted_enctypes default etypes
> > for
> > permitted_enctypes: 18 17 16 23 1 3.
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > replay cache for alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org> is null.
> > object 0: 1429862199082/82299
> > >>> KrbApReq: authenticate succeed.
> > Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> > mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> > io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> > 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
> >
> > Results :
> >
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
> >
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] BUILD SUCCESS
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] Total time: 6.770 s
> > [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> > 13M/262M [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [drankye@zkdesk cxf-kerberos-kerby]$
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:31 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > There's no rush with any of this! I am just playing around with Kerby.
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, similar issue but this time is TransitedEncoding now. We need
> > to go thru the codes to make sure service ticket is correctly
> > filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:01 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok that looks good, the client is now working again, and I'm getting
> > past the decoding of the client name. Now there is another error on
> > the service side :-)
> >
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.
> java:76)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.j
> ava:133)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > This should fix the problem, but need some clean up. Will commit it
> > after your confirmation.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:50 PM
> >
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> > Subject: RE: Kerby GSS tests?
> >
> > Would you have a try with this? I will double check what’s the
> > correct way. Thanks.
> >
> > @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> > EncryptionType encryptionType = getEncryptionType();
> > EncryptionKey serverKey =
> > getServerEntry().getKeys().get(encryptionType
> >
> > - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> > + PrincipalName ticketPrincipal =
> > + request.getReqBody().getSname();
> >
> > EncTicketPart encTicketPart = new EncTicketPart();
> > KdcConfig config = kdcContext.getConfig();
> > (END)
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > It appears there is a regression in the fix, I'm now getting a
> > client
> > error:
> >
> > KrbException: Message stream modified (41)
> > at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> > at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> > at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> > at
> sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUti
> l.java:309)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Credent
> ialsUtil.java:115)
> > at
> > sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> > at
> > sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:
> > 17
> > 9)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm would you check the latest fix? Just committed, though I’m not
> > perfectly sure. It may has some other issues, but will check some
> > time later, when having tests in hand.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:10 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Yes you’re right. I’m working on a fix. Will let you know soon.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:09 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The first time we hit "issueTicket" the CName is correct "
> > alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> > However, on the second time it is blank. This sounds like a similar
> > bug that you fixed for when the cname was not in the request?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > >> So now my client is successfully communicating with Kerby!
> > It’s exciting! Thanks a lot.
> >
> > >>I'm getting an error in GSS when parsing the principal name
> > Looks like it failed to parse cname in encpart in the service ticket.
> > Would you debug into the issueTicket() in KdcRequest and check what
> > cname is set into the field?
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 6:43 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok I've figured out what the problem was. I was creating two
> > principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> > http://service.ws.apache.org>". The default value for the
> > TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> > the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>"
> > key was used first, and the other key was used for TGS. I solved it
> > by just specifying "krbtgt/
> > service.ws.apache.org<http://service.ws.apache.org>" as the
> TGS_PRINCIPAL in KdcConfig.
> > So now my client is successfully communicating with Kerby! However,
> > I'm now running into a problem on the service side. I'm getting an
> > error in GSS when parsing the principal name:
> >
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> > at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at
> > sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > Any ideas?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > It may be caused by bad backend? What’s backend you used? I thought
> > two keys should be the same anyway.
> >
> > From: Zheng, Kai
> > Sent: Thursday, April 23, 2015 5:52 PM
> > To: 'coheigea@apache.org<ma...@apache.org>'
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Oh bad, looks like the key use to issue ticket isn’t the same one to
> > decrypt it in TgsRequest processing. The encryption type should be
> > the same, right, but then why we two different key values or keys?
> > Would you debug more? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 5:38 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > The two keys are not the same. They have the same encoding length +
> > kvno + tagno, but different byte[] content.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > It looks strange to me.
> > Would you debug and check the two keys are the same in that place
> > and the other place in KDC side KdcRequest:400:
> > EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> > serverKey, KeyUsage.KDC_REP_TICKET);
> >
> > Thanks. I’m going to sleep now. See you tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Wednesday, April 22, 2015 11:15 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I get the same error (decryption error) with this patch.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > The fix would be as follows. Would you verify and commit it if OK?
> Thanks.
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listItera
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > Ticket ticket = apReq.getTicket();
> > + EncryptionType encType =
> ticket.getEncryptedEncPart().getEType();
> > + EncryptionKey tgsKey =
> > + getTgsEntry().getKeys().get(encType);
> > if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> > }
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 10:46 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > >> Are we sure that the tgsKey above is the right key to decrpyt the
> > request?
> > Yes, the ticket there to decrypt is actually for TGS to interpret
> > and validate, a tgs key should be used. I’m still thinking about how
> > to get the encryption type right. It’s a certain one this time.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 10:01 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Looks good thanks! The next problem is an NPE in EncryptionHandler.
> > This is caused by a similar issue to before:
> >
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server/request/TgsRequest.java
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> > TgsRequest extends KdcRequest {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> > }
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listIterator().next();
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > + EncryptionKey tgsKey = null;
> > + for (EncryptionType encType :
> > getKdcReq().getReqBody().getEtypes()) {
> > + if (getTgsEntry().getKeys().containsKey(encType)) {
> > + tgsKey = getTgsEntry().getKeys().get(encType);
> > + break;
> > + }
> > + }
> > +
> > However, this patch results in the error:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> > decrypted field failed
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.
> java:116)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:160)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:148)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(Encryp
> tionHandler.java:165)
> > at
> >
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(Encryption
> Util.java:132)
> > at
> > org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthe
> > nt
> > icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> > right key to decrpyt the request?
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > Would you check out the fix below and verify it? Thanks!
> >
> > commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> > Author: Drankye <dr...@gmail.com>>
> > Date: Wed Apr 22 21:25:21 2015 +0800
> >
> > Fixed the issue that cname field in KdcReqBody should not be
> > used in TgsReq
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 8:36 PM
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> >
> > Subject: RE: Kerby GSS tests?
> >
> > I just checked the codes in MIT Kerberos. It was clear we should use
> > the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> > field in KdcReq is only used in AsReq, not used in TgsReq.
> > I will have a fix for this shortly.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Wednesday, April 22, 2015 7:37 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Thanks for your good progress and analysis. I’m not sure how KDC
> > would handle in such case, but a possibility is to use the client
> > principal name in the TGT ticket, would you inspect the fields of
> > the passed TGT and use the client field in it, when it’s null in the
> > KdcReq? I will check and make sure which way we should go later. Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 6:17 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok with the current code I've made some progress - I can now
> > successfully get a TGT from Kerby. However, I'm running into a
> > puzzling issue when trying to get a service key. Essentially, the
> > clientPrincipal in
> > KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> > This means that it just tries to retrieve the client Principal using
> > @realm, and this fails.
> > On the first TGT pass, the client + server principals in checkClient
> > look
> > like:
> >
> > Client PRINC: alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>
> > Client PRINC type: NT_PRINCIPAL
> > Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_SRV_INST
> > On the second call:
> >
> > Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> > Client PRINC type: NT_UNKNOWN
> > Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_UNKNOWN
> > The SName looks find. But the CName is missing. I know this code
> > works fine with the KDC in Apache Directory, so we must be doing
> > something odd with the parsing in Kerby.
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > I thought it’s good to have the following fix for now, as it
> > processes the enctypes list from client from first to end. I just
> > fired a follow-on issue to double check this.
> > https://issues.apache.org/jira/browse/DIRKRB-236
> >
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 8:53 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kiran,
> >
> > > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side
> > Is there any existing code in Apache Directory along these lines?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari
> > <kayyagari@apache.org <ma...@apache.org>> wrote:
> >
> >
> > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > Yes it’s a great fix! May be we could also update our related kdc
> > test to repeat the issue and guard the fix? In our existing tests,
> > the enctypes used in KrbClient are the same with the ones in
> > KdcServer side, so we don’t find the issue until now. Yes, client
> > may very likely request different enctypes that the KdcServer
> > doesn’t
> support/enable yet.
> >
> > yes, clients can send different enctypes depending the platform they
> > are running on.
> >
> > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side and then pick the best from the
> > ones requested by the client.
> > Thanks again.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:33 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I've found another bug. We are just picking the first desired
> > encryption type in KdcRequest.checkClient(). However, we may not
> > actually have this key. This leads to an NPE. Example:
> > We are requesting:
> >
> > aes256-cts-hmac-sha1-96 18
> > aes128-cts-hmac-sha1-96 17
> > des3-cbc-sha1 16
> > arcfour-hmac 23
> > des-cbc-crc 1
> > des-cbc-md5 3
> >
> > We pick the first one...however we only have the following keys stored:
> >
> > des3-cbc-sha1 16
> > aes128-cts-hmac-sha1-96 17
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 2165e17..e6bcef0 100644
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> > KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> > setClientEntry(clientEntry);
> >
> > - EncryptionType encType =
> > request.getReqBody().getEtypes().listIterator(
> > - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> > - setClientKey(clientKey);
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> > }
> >
> > protected void preauth() throws KrbException { Colm.
> >
> >
> > On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Yep I will do!
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, it looks like a good fix, 0 is there instead of null, for time
> fields
> > in kdc request. Would you double check other time values by the way?
> Thanks!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:11 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The problem above is that the "end time" is 0 instead of "null".
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 3d49af3..23275fc 100644
> > ---
> >
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > +++
> >
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> > }
> >
> > KerberosTime krbEndTime = request.getReqBody().getTill();
> > - if (krbEndTime == null) {
> > + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> > krbEndTime =
> > krbStartTime.extend(config.getMaximumTicketLifetime()
> > } else if (krbStartTime.greaterThan(krbEndTime)) {
> > throw new
> > KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> >
> > 2. Please disable preauth in KDC side or require preauth in client
> > side. Looks like client didn’t send preauth data but KDC required it.
> >
> > Ok I got a bit further by doing this. However, from what I can find
> > out, the GSS client code should be sending the Pre authentication
> > data (and there appears to be no option to disable it). So I think
> > there may be a
> bug
> > in how Kerby is processing the header? Should we log a JIRA to track
> this?
> > The error I now get (when disabling pre auth in Kerby) is:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
> later
> > than end time
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(K
> dcRequest.java:376)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:96)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > at
> >
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKd
> cHandler.java:51)
> > Any ideas? The Kerby server + CXF client are both on the same machine...
> > Colm.
> >
> >
> > If you don’t want to trouble with the config stuff, please just
> > change
> the
> > default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 6:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Actually I spoke too soon, I do know how to reproduce the
> > "pre-authentication" error. Simply uncomment the line
> > "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the
> > test. If
> I
> > put a printStackTrace in the NettyKdcServerImpl, I see:
> >
> > Error occured while processing request:Generic error (description in
> > e-text)
> > SocketTimeOutException with attempt: 2
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =3,
> > #bytes=169
> > Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger
> > info
> > INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id:
> > 0xbfe95a70,
> /
> > 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> > http://127.0.0.1:9002>]
> > org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> > (description in e-text)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRe
> quest.java:255)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:94)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> > Thanks for your response. I have a test-case of sorts that shows the
> > interop failure (although I can't reproduce the issue I reported
> yesterday
> > about the preauthentication data).
> >
> >
> >
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerbe
> ros-kerby
> > Run it with "mvn clean install". You may need the install the parent
> > module as well before running this, which is one level up.
> > The test sets up a Kerby server, and I have a @Ignore'd test using
> > Kerby client API to successfully communicate with it. Then I have a
> > Apache CXF-based test which uses the Kerberos functionality here
> > (based on GSS)
> to
> > get a service ticket. If I put printStackTrace in the
> > DefaultKdcHandler
> the
> > output looks like:
> >
> > Loaded from Java config
> > >>> KdcAccessibility: reset
> > >>> KdcAccessibility: reset
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > >>> KrbAsReq creating message
> > >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> > retries =3, #bytes=169
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =1,
> > #bytes=169
> > java.net.SocketTimeoutException: Read timed out
> > at java.net.SocketInputStream.socketRead0(Native Method)
> > at java.net.SocketInputStream.read(SocketInputStream.java:152)
> > at java.net.SocketInputStream.read(SocketInputStream.java:122)
> > at java.net.SocketInputStream.read(SocketInputStream.java:210)
> > at java.io.DataInputStream.readInt(DataInputStream.java:387)
> > at
> >
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessag
> e(KrbTcpTransport.java:54)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(Defau
> ltKdcHandler.java:46)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > >>>DEBUG: TCPClient could not read length field KrbKdcReq send:
> > >>>#bytes read=0
> > Any ideas?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > We haven’t any test for GSS client against Kerby yet, though we do
> > have tests in protocol level for ApReq (in kerb-core-test module).
> > We might
> look
> > at existing ApacheDS Kerberos codes to see if any such end to end
> > tests
> to
> > port.
> >
> > You’re right, current UDP support for KdcNetwork and NettyKdcNetwork
> > are to be done yet. I originally got them done some days ago, but
> > recently I was extremely busy with other projects, so kinds of
> > delayed. Sure JIRAs would be good to record them.
> >
> > For the issue you ran into, do you have test codes to repeat it, so
> > we
> may
> > have the chance to look at it? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Monday, April 20, 2015 10:40 PM
> > To: Apache Directory Developers List
> > Subject: Kerby GSS tests?
> >
> > Hi all,
> >
> > Are there any tests in the source (or has anyone successfully
> > tested) a Java GSS client -> Apache Kerby?
> > The first issue I ran into was that neither the KdcNetwork nor the
> > NettyKdcNetwork work with UDP. Is there a JIRA for this (or any
> > plans to fix it)?
> > I could work around the above by setting "udp_preference_limit = 1".
> > However, I then run into an issue where it fails due to no
> > pre-authentication data in the request. Are we sure that this
> > parsing is working correctly?
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Li, Jiajia" <ji...@intel.com>.
Hi, Colm,
I Fail to run GSSInteropTest, the detail in
https://issues.apache.org/jira/browse/DIRKRB-246
Do you have any idea to fix it?
Thanks
Jiajia
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 29, 2015 9:30 PM
To: kerby@directory.apache.org; coheigea@apache.org
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Will we also be supporting it for the Default case as opposed to the Netty case?
Sure, we will.
>> there is no validation of the service ticket. I will add this in
That's great. And also, based on this work, it would be possible to have another one in the SASL framework.
Regards,
Kai
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 29, 2015 8:50 PM
To: Zheng, Kai
Cc: kerby@directory.apache.org; Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Cool, I'll try out the UDP support. Will we also be supporting it for the Default case as opposed to the Netty case?
I'm not really sure if my test-case qualifies as an end-to-end test...there is no validation of the service ticket. I will add this in...
Colm.
On Wed, Apr 29, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Thanks Colm for the great work!
>
> Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
>
> By the way, Yaning made the UDP support happen for the NettyKdcNetwork
> today,
> https://issues.apache.org/jira/browse/DIRKRB-231
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 29, 2015 6:38 PM
> To: kerby@directory.apache.org
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Ok done!
>
> Repository: directory-kerby
> Updated Branches:
> refs/heads/master e452f1854 -> eb2e4c1ae
>
>
> Adding a GSS unit test
>
>
> Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
> Tree:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
> Diff:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
>
> Colm.
>
> On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> > Colm,
> >
> > Yes it’s a known issue due to incomplete implementation. When the
> > following one is resolved, I thought we could get back to this
> > verifying the function. I will hopefully work on it recently.
> > https://issues.apache.org/jira/browse/DIRKRB-235
> >
> > By the way, is it doable to port your end to end tests into Kerby,
> > without introducing the many deps? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, April 27, 2015 6:46 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Thanks, everything is working now :-) The remaining issue is that
> > the tests are failing when pre-auth is enabled. Do you want me to
> > start looking into this, or are there known issues here?
> > Colm.
> >
> > On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > It’s done now. The root cause is due to the incorrect TGS principal
> > construction. Please check out latest codes and also apply the
> > following change to your test project.
> >
> > Regards,
> > Kai
> >
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> > @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> > }
> >
> > @org.junit.Test
> > - @org.junit.Ignore
> > + //@org.junit.Ignore<ma...@org.junit.Ignore>
> > public void unitTest() throws Exception {
> > KrbClient client = new KrbClient();
> >
> > diff --git
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > b/apache/cxf/cxf-k
> > index 3806a70..802baa0 100644
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Friday, April 24, 2015 8:12 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > So it’s another issue existing in client side, right? I checked our
> > today’s changes and found nothing related to the issue. It may be
> > not caused by the fix of previous issue.
> >
> > I can’t debug on your project due to maven module deps. I saw no
> > much difference from your test case with Kerby’s, but wonder why
> > it’s ok in Kerby project.
> > Will continue to investigate it tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, April 24, 2015 5:52 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Excellent thanks! However, now the unit test using the Kerby client
> > API fails :-) The problem is in getting the TGT. Using the GSS
> > client API, the value for the "PrincipalName principal =
> > request.getReqBody().getSname();" in
> > KdcRequest.checkServer() is:
> >
> > krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> > However, using the Kerby client API it's:
> >
> > krbtgt
> > and hence an error is thrown, as this principal is not stored. Any
> > ideas here? You can reproduce just by updating my github project,
> > and removing the @Ignore annotation from the "unitTest".
> > Colm.
> >
> > On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > It’s done! Below is my test running your test project. Please check
> > latest codes and verify it, thanks!
> >
> > >>>DEBUG: TCPClient reading 594 bytes KrbKdcReq send: #bytes
> > >>>read=594
> > >>> KdcAccessibility: remove localhost:9002
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> > http://service.ws.apache.org>
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > Using builtin default etypes for permitted_enctypes default etypes
> > for
> > permitted_enctypes: 18 17 16 23 1 3.
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > replay cache for alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org> is null.
> > object 0: 1429862199082/82299
> > >>> KrbApReq: authenticate succeed.
> > Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> > mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> > io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> > 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
> >
> > Results :
> >
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
> >
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] BUILD SUCCESS
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] Total time: 6.770 s
> > [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> > 13M/262M [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [drankye@zkdesk cxf-kerberos-kerby]$
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:31 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > There's no rush with any of this! I am just playing around with Kerby.
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, similar issue but this time is TransitedEncoding now. We need
> > to go thru the codes to make sure service ticket is correctly
> > filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:01 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok that looks good, the client is now working again, and I'm getting
> > past the decoding of the client name. Now there is another error on
> > the service side :-)
> >
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.
> java:76)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.j
> ava:133)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > This should fix the problem, but need some clean up. Will commit it
> > after your confirmation.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:50 PM
> >
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> > Subject: RE: Kerby GSS tests?
> >
> > Would you have a try with this? I will double check what’s the
> > correct way. Thanks.
> >
> > @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> > EncryptionType encryptionType = getEncryptionType();
> > EncryptionKey serverKey =
> > getServerEntry().getKeys().get(encryptionType
> >
> > - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> > + PrincipalName ticketPrincipal =
> > + request.getReqBody().getSname();
> >
> > EncTicketPart encTicketPart = new EncTicketPart();
> > KdcConfig config = kdcContext.getConfig();
> > (END)
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > It appears there is a regression in the fix, I'm now getting a
> > client
> > error:
> >
> > KrbException: Message stream modified (41)
> > at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> > at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> > at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> > at
> sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUti
> l.java:309)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Credent
> ialsUtil.java:115)
> > at
> > sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> > at
> > sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:
> > 17
> > 9)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm would you check the latest fix? Just committed, though I’m not
> > perfectly sure. It may has some other issues, but will check some
> > time later, when having tests in hand.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:10 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Yes you’re right. I’m working on a fix. Will let you know soon.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:09 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The first time we hit "issueTicket" the CName is correct "
> > alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> > However, on the second time it is blank. This sounds like a similar
> > bug that you fixed for when the cname was not in the request?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > >> So now my client is successfully communicating with Kerby!
> > It’s exciting! Thanks a lot.
> >
> > >>I'm getting an error in GSS when parsing the principal name
> > Looks like it failed to parse cname in encpart in the service ticket.
> > Would you debug into the issueTicket() in KdcRequest and check what
> > cname is set into the field?
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 6:43 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok I've figured out what the problem was. I was creating two
> > principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> > http://service.ws.apache.org>". The default value for the
> > TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> > the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>"
> > key was used first, and the other key was used for TGS. I solved it
> > by just specifying "krbtgt/
> > service.ws.apache.org<http://service.ws.apache.org>" as the
> TGS_PRINCIPAL in KdcConfig.
> > So now my client is successfully communicating with Kerby! However,
> > I'm now running into a problem on the service side. I'm getting an
> > error in GSS when parsing the principal name:
> >
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> > at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at
> > sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > Any ideas?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > It may be caused by bad backend? What’s backend you used? I thought
> > two keys should be the same anyway.
> >
> > From: Zheng, Kai
> > Sent: Thursday, April 23, 2015 5:52 PM
> > To: 'coheigea@apache.org<ma...@apache.org>'
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Oh bad, looks like the key use to issue ticket isn’t the same one to
> > decrypt it in TgsRequest processing. The encryption type should be
> > the same, right, but then why we two different key values or keys?
> > Would you debug more? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 5:38 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > The two keys are not the same. They have the same encoding length +
> > kvno + tagno, but different byte[] content.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > It looks strange to me.
> > Would you debug and check the two keys are the same in that place
> > and the other place in KDC side KdcRequest:400:
> > EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> > serverKey, KeyUsage.KDC_REP_TICKET);
> >
> > Thanks. I’m going to sleep now. See you tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Wednesday, April 22, 2015 11:15 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I get the same error (decryption error) with this patch.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > The fix would be as follows. Would you verify and commit it if OK?
> Thanks.
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listItera
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > Ticket ticket = apReq.getTicket();
> > + EncryptionType encType =
> ticket.getEncryptedEncPart().getEType();
> > + EncryptionKey tgsKey =
> > + getTgsEntry().getKeys().get(encType);
> > if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> > }
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 10:46 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > >> Are we sure that the tgsKey above is the right key to decrpyt the
> > request?
> > Yes, the ticket there to decrypt is actually for TGS to interpret
> > and validate, a tgs key should be used. I’m still thinking about how
> > to get the encryption type right. It’s a certain one this time.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 10:01 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Looks good thanks! The next problem is an NPE in EncryptionHandler.
> > This is caused by a similar issue to before:
> >
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server/request/TgsRequest.java
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> > TgsRequest extends KdcRequest {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> > }
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listIterator().next();
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > + EncryptionKey tgsKey = null;
> > + for (EncryptionType encType :
> > getKdcReq().getReqBody().getEtypes()) {
> > + if (getTgsEntry().getKeys().containsKey(encType)) {
> > + tgsKey = getTgsEntry().getKeys().get(encType);
> > + break;
> > + }
> > + }
> > +
> > However, this patch results in the error:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> > decrypted field failed
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.
> java:116)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:160)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:148)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(Encryp
> tionHandler.java:165)
> > at
> >
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(Encryption
> Util.java:132)
> > at
> > org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthe
> > nt
> > icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> > right key to decrpyt the request?
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > Would you check out the fix below and verify it? Thanks!
> >
> > commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> > Author: Drankye <dr...@gmail.com>>
> > Date: Wed Apr 22 21:25:21 2015 +0800
> >
> > Fixed the issue that cname field in KdcReqBody should not be
> > used in TgsReq
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 8:36 PM
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> >
> > Subject: RE: Kerby GSS tests?
> >
> > I just checked the codes in MIT Kerberos. It was clear we should use
> > the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> > field in KdcReq is only used in AsReq, not used in TgsReq.
> > I will have a fix for this shortly.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Wednesday, April 22, 2015 7:37 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Thanks for your good progress and analysis. I’m not sure how KDC
> > would handle in such case, but a possibility is to use the client
> > principal name in the TGT ticket, would you inspect the fields of
> > the passed TGT and use the client field in it, when it’s null in the
> > KdcReq? I will check and make sure which way we should go later. Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 6:17 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok with the current code I've made some progress - I can now
> > successfully get a TGT from Kerby. However, I'm running into a
> > puzzling issue when trying to get a service key. Essentially, the
> > clientPrincipal in
> > KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> > This means that it just tries to retrieve the client Principal using
> > @realm, and this fails.
> > On the first TGT pass, the client + server principals in checkClient
> > look
> > like:
> >
> > Client PRINC: alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>
> > Client PRINC type: NT_PRINCIPAL
> > Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_SRV_INST
> > On the second call:
> >
> > Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> > Client PRINC type: NT_UNKNOWN
> > Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_UNKNOWN
> > The SName looks find. But the CName is missing. I know this code
> > works fine with the KDC in Apache Directory, so we must be doing
> > something odd with the parsing in Kerby.
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > I thought it’s good to have the following fix for now, as it
> > processes the enctypes list from client from first to end. I just
> > fired a follow-on issue to double check this.
> > https://issues.apache.org/jira/browse/DIRKRB-236
> >
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 8:53 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kiran,
> >
> > > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side
> > Is there any existing code in Apache Directory along these lines?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari
> > <kayyagari@apache.org <ma...@apache.org>> wrote:
> >
> >
> > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > Yes it’s a great fix! May be we could also update our related kdc
> > test to repeat the issue and guard the fix? In our existing tests,
> > the enctypes used in KrbClient are the same with the ones in
> > KdcServer side, so we don’t find the issue until now. Yes, client
> > may very likely request different enctypes that the KdcServer
> > doesn’t
> support/enable yet.
> >
> > yes, clients can send different enctypes depending the platform they
> > are running on.
> >
> > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side and then pick the best from the
> > ones requested by the client.
> > Thanks again.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:33 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I've found another bug. We are just picking the first desired
> > encryption type in KdcRequest.checkClient(). However, we may not
> > actually have this key. This leads to an NPE. Example:
> > We are requesting:
> >
> > aes256-cts-hmac-sha1-96 18
> > aes128-cts-hmac-sha1-96 17
> > des3-cbc-sha1 16
> > arcfour-hmac 23
> > des-cbc-crc 1
> > des-cbc-md5 3
> >
> > We pick the first one...however we only have the following keys stored:
> >
> > des3-cbc-sha1 16
> > aes128-cts-hmac-sha1-96 17
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 2165e17..e6bcef0 100644
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> > KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> > setClientEntry(clientEntry);
> >
> > - EncryptionType encType =
> > request.getReqBody().getEtypes().listIterator(
> > - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> > - setClientKey(clientKey);
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> > }
> >
> > protected void preauth() throws KrbException { Colm.
> >
> >
> > On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Yep I will do!
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, it looks like a good fix, 0 is there instead of null, for time
> fields
> > in kdc request. Would you double check other time values by the way?
> Thanks!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:11 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The problem above is that the "end time" is 0 instead of "null".
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 3d49af3..23275fc 100644
> > ---
> >
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > +++
> >
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> > }
> >
> > KerberosTime krbEndTime = request.getReqBody().getTill();
> > - if (krbEndTime == null) {
> > + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> > krbEndTime =
> > krbStartTime.extend(config.getMaximumTicketLifetime()
> > } else if (krbStartTime.greaterThan(krbEndTime)) {
> > throw new
> > KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> >
> > 2. Please disable preauth in KDC side or require preauth in client
> > side. Looks like client didn’t send preauth data but KDC required it.
> >
> > Ok I got a bit further by doing this. However, from what I can find
> > out, the GSS client code should be sending the Pre authentication
> > data (and there appears to be no option to disable it). So I think
> > there may be a
> bug
> > in how Kerby is processing the header? Should we log a JIRA to track
> this?
> > The error I now get (when disabling pre auth in Kerby) is:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
> later
> > than end time
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(K
> dcRequest.java:376)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:96)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > at
> >
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKd
> cHandler.java:51)
> > Any ideas? The Kerby server + CXF client are both on the same machine...
> > Colm.
> >
> >
> > If you don’t want to trouble with the config stuff, please just
> > change
> the
> > default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 6:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Actually I spoke too soon, I do know how to reproduce the
> > "pre-authentication" error. Simply uncomment the line
> > "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the
> > test. If
> I
> > put a printStackTrace in the NettyKdcServerImpl, I see:
> >
> > Error occured while processing request:Generic error (description in
> > e-text)
> > SocketTimeOutException with attempt: 2
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =3,
> > #bytes=169
> > Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger
> > info
> > INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id:
> > 0xbfe95a70,
> /
> > 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> > http://127.0.0.1:9002>]
> > org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> > (description in e-text)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRe
> quest.java:255)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:94)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> > Thanks for your response. I have a test-case of sorts that shows the
> > interop failure (although I can't reproduce the issue I reported
> yesterday
> > about the preauthentication data).
> >
> >
> >
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerbe
> ros-kerby
> > Run it with "mvn clean install". You may need the install the parent
> > module as well before running this, which is one level up.
> > The test sets up a Kerby server, and I have a @Ignore'd test using
> > Kerby client API to successfully communicate with it. Then I have a
> > Apache CXF-based test which uses the Kerberos functionality here
> > (based on GSS)
> to
> > get a service ticket. If I put printStackTrace in the
> > DefaultKdcHandler
> the
> > output looks like:
> >
> > Loaded from Java config
> > >>> KdcAccessibility: reset
> > >>> KdcAccessibility: reset
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > >>> KrbAsReq creating message
> > >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> > retries =3, #bytes=169
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =1,
> > #bytes=169
> > java.net.SocketTimeoutException: Read timed out
> > at java.net.SocketInputStream.socketRead0(Native Method)
> > at java.net.SocketInputStream.read(SocketInputStream.java:152)
> > at java.net.SocketInputStream.read(SocketInputStream.java:122)
> > at java.net.SocketInputStream.read(SocketInputStream.java:210)
> > at java.io.DataInputStream.readInt(DataInputStream.java:387)
> > at
> >
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessag
> e(KrbTcpTransport.java:54)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(Defau
> ltKdcHandler.java:46)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > >>>DEBUG: TCPClient could not read length field KrbKdcReq send:
> > >>>#bytes read=0
> > Any ideas?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > We haven’t any test for GSS client against Kerby yet, though we do
> > have tests in protocol level for ApReq (in kerb-core-test module).
> > We might
> look
> > at existing ApacheDS Kerberos codes to see if any such end to end
> > tests
> to
> > port.
> >
> > You’re right, current UDP support for KdcNetwork and NettyKdcNetwork
> > are to be done yet. I originally got them done some days ago, but
> > recently I was extremely busy with other projects, so kinds of
> > delayed. Sure JIRAs would be good to record them.
> >
> > For the issue you ran into, do you have test codes to repeat it, so
> > we
> may
> > have the chance to look at it? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Monday, April 20, 2015 10:40 PM
> > To: Apache Directory Developers List
> > Subject: Kerby GSS tests?
> >
> > Hi all,
> >
> > Are there any tests in the source (or has anyone successfully
> > tested) a Java GSS client -> Apache Kerby?
> > The first issue I ran into was that neither the KdcNetwork nor the
> > NettyKdcNetwork work with UDP. Is there a JIRA for this (or any
> > plans to fix it)?
> > I could work around the above by setting "udp_preference_limit = 1".
> > However, I then run into an issue where it fails due to no
> > pre-authentication data in the request. Are we sure that this
> > parsing is working correctly?
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
>> Will we also be supporting it for the Default case as opposed to the Netty case?
Sure, we will.
>> there is no validation of the service ticket. I will add this in
That's great. And also, based on this work, it would be possible to have another one in the SASL framework.
Regards,
Kai
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 29, 2015 8:50 PM
To: Zheng, Kai
Cc: kerby@directory.apache.org; Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Cool, I'll try out the UDP support. Will we also be supporting it for the Default case as opposed to the Netty case?
I'm not really sure if my test-case qualifies as an end-to-end test...there is no validation of the service ticket. I will add this in...
Colm.
On Wed, Apr 29, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Thanks Colm for the great work!
>
> Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
>
> By the way, Yaning made the UDP support happen for the NettyKdcNetwork
> today,
> https://issues.apache.org/jira/browse/DIRKRB-231
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 29, 2015 6:38 PM
> To: kerby@directory.apache.org
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Ok done!
>
> Repository: directory-kerby
> Updated Branches:
> refs/heads/master e452f1854 -> eb2e4c1ae
>
>
> Adding a GSS unit test
>
>
> Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
> Tree:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
> Diff:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
>
> Colm.
>
> On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> > Colm,
> >
> > Yes it’s a known issue due to incomplete implementation. When the
> > following one is resolved, I thought we could get back to this
> > verifying the function. I will hopefully work on it recently.
> > https://issues.apache.org/jira/browse/DIRKRB-235
> >
> > By the way, is it doable to port your end to end tests into Kerby,
> > without introducing the many deps? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, April 27, 2015 6:46 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Thanks, everything is working now :-) The remaining issue is that
> > the tests are failing when pre-auth is enabled. Do you want me to
> > start looking into this, or are there known issues here?
> > Colm.
> >
> > On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > It’s done now. The root cause is due to the incorrect TGS principal
> > construction. Please check out latest codes and also apply the
> > following change to your test project.
> >
> > Regards,
> > Kai
> >
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> > @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> > }
> >
> > @org.junit.Test
> > - @org.junit.Ignore
> > + //@org.junit.Ignore<ma...@org.junit.Ignore>
> > public void unitTest() throws Exception {
> > KrbClient client = new KrbClient();
> >
> > diff --git
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > b/apache/cxf/cxf-k
> > index 3806a70..802baa0 100644
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Friday, April 24, 2015 8:12 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > So it’s another issue existing in client side, right? I checked our
> > today’s changes and found nothing related to the issue. It may be
> > not caused by the fix of previous issue.
> >
> > I can’t debug on your project due to maven module deps. I saw no
> > much difference from your test case with Kerby’s, but wonder why
> > it’s ok in Kerby project.
> > Will continue to investigate it tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, April 24, 2015 5:52 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Excellent thanks! However, now the unit test using the Kerby client
> > API fails :-) The problem is in getting the TGT. Using the GSS
> > client API, the value for the "PrincipalName principal =
> > request.getReqBody().getSname();" in
> > KdcRequest.checkServer() is:
> >
> > krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> > However, using the Kerby client API it's:
> >
> > krbtgt
> > and hence an error is thrown, as this principal is not stored. Any
> > ideas here? You can reproduce just by updating my github project,
> > and removing the @Ignore annotation from the "unitTest".
> > Colm.
> >
> > On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > It’s done! Below is my test running your test project. Please check
> > latest codes and verify it, thanks!
> >
> > >>>DEBUG: TCPClient reading 594 bytes KrbKdcReq send: #bytes
> > >>>read=594
> > >>> KdcAccessibility: remove localhost:9002
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> > http://service.ws.apache.org>
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > Using builtin default etypes for permitted_enctypes default etypes
> > for
> > permitted_enctypes: 18 17 16 23 1 3.
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > replay cache for alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org> is null.
> > object 0: 1429862199082/82299
> > >>> KrbApReq: authenticate succeed.
> > Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> > mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> > io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> > 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
> >
> > Results :
> >
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
> >
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] BUILD SUCCESS
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] Total time: 6.770 s
> > [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> > 13M/262M [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [drankye@zkdesk cxf-kerberos-kerby]$
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:31 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > There's no rush with any of this! I am just playing around with Kerby.
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, similar issue but this time is TransitedEncoding now. We need
> > to go thru the codes to make sure service ticket is correctly
> > filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:01 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok that looks good, the client is now working again, and I'm getting
> > past the decoding of the client name. Now there is another error on
> > the service side :-)
> >
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.
> java:76)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.j
> ava:133)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > This should fix the problem, but need some clean up. Will commit it
> > after your confirmation.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:50 PM
> >
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> > Subject: RE: Kerby GSS tests?
> >
> > Would you have a try with this? I will double check what’s the
> > correct way. Thanks.
> >
> > @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> > EncryptionType encryptionType = getEncryptionType();
> > EncryptionKey serverKey =
> > getServerEntry().getKeys().get(encryptionType
> >
> > - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> > + PrincipalName ticketPrincipal =
> > + request.getReqBody().getSname();
> >
> > EncTicketPart encTicketPart = new EncTicketPart();
> > KdcConfig config = kdcContext.getConfig();
> > (END)
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > It appears there is a regression in the fix, I'm now getting a
> > client
> > error:
> >
> > KrbException: Message stream modified (41)
> > at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> > at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> > at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> > at
> sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUti
> l.java:309)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Credent
> ialsUtil.java:115)
> > at
> > sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> > at
> > sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:
> > 17
> > 9)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm would you check the latest fix? Just committed, though I’m not
> > perfectly sure. It may has some other issues, but will check some
> > time later, when having tests in hand.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:10 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Yes you’re right. I’m working on a fix. Will let you know soon.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:09 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The first time we hit "issueTicket" the CName is correct "
> > alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> > However, on the second time it is blank. This sounds like a similar
> > bug that you fixed for when the cname was not in the request?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > >> So now my client is successfully communicating with Kerby!
> > It’s exciting! Thanks a lot.
> >
> > >>I'm getting an error in GSS when parsing the principal name
> > Looks like it failed to parse cname in encpart in the service ticket.
> > Would you debug into the issueTicket() in KdcRequest and check what
> > cname is set into the field?
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 6:43 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok I've figured out what the problem was. I was creating two
> > principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> > http://service.ws.apache.org>". The default value for the
> > TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> > the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>"
> > key was used first, and the other key was used for TGS. I solved it
> > by just specifying "krbtgt/
> > service.ws.apache.org<http://service.ws.apache.org>" as the
> TGS_PRINCIPAL in KdcConfig.
> > So now my client is successfully communicating with Kerby! However,
> > I'm now running into a problem on the service side. I'm getting an
> > error in GSS when parsing the principal name:
> >
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> > at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at
> > sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > Any ideas?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > It may be caused by bad backend? What’s backend you used? I thought
> > two keys should be the same anyway.
> >
> > From: Zheng, Kai
> > Sent: Thursday, April 23, 2015 5:52 PM
> > To: 'coheigea@apache.org<ma...@apache.org>'
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Oh bad, looks like the key use to issue ticket isn’t the same one to
> > decrypt it in TgsRequest processing. The encryption type should be
> > the same, right, but then why we two different key values or keys?
> > Would you debug more? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 5:38 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > The two keys are not the same. They have the same encoding length +
> > kvno + tagno, but different byte[] content.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > It looks strange to me.
> > Would you debug and check the two keys are the same in that place
> > and the other place in KDC side KdcRequest:400:
> > EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> > serverKey, KeyUsage.KDC_REP_TICKET);
> >
> > Thanks. I’m going to sleep now. See you tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Wednesday, April 22, 2015 11:15 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I get the same error (decryption error) with this patch.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > The fix would be as follows. Would you verify and commit it if OK?
> Thanks.
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listItera
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > Ticket ticket = apReq.getTicket();
> > + EncryptionType encType =
> ticket.getEncryptedEncPart().getEType();
> > + EncryptionKey tgsKey =
> > + getTgsEntry().getKeys().get(encType);
> > if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> > }
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 10:46 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > >> Are we sure that the tgsKey above is the right key to decrpyt the
> > request?
> > Yes, the ticket there to decrypt is actually for TGS to interpret
> > and validate, a tgs key should be used. I’m still thinking about how
> > to get the encryption type right. It’s a certain one this time.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 10:01 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Looks good thanks! The next problem is an NPE in EncryptionHandler.
> > This is caused by a similar issue to before:
> >
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server/request/TgsRequest.java
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> > TgsRequest extends KdcRequest {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> > }
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listIterator().next();
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > + EncryptionKey tgsKey = null;
> > + for (EncryptionType encType :
> > getKdcReq().getReqBody().getEtypes()) {
> > + if (getTgsEntry().getKeys().containsKey(encType)) {
> > + tgsKey = getTgsEntry().getKeys().get(encType);
> > + break;
> > + }
> > + }
> > +
> > However, this patch results in the error:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> > decrypted field failed
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.
> java:116)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:160)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:148)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(Encryp
> tionHandler.java:165)
> > at
> >
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(Encryption
> Util.java:132)
> > at
> > org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthe
> > nt
> > icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> > right key to decrpyt the request?
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > Would you check out the fix below and verify it? Thanks!
> >
> > commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> > Author: Drankye <dr...@gmail.com>>
> > Date: Wed Apr 22 21:25:21 2015 +0800
> >
> > Fixed the issue that cname field in KdcReqBody should not be
> > used in TgsReq
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 8:36 PM
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> >
> > Subject: RE: Kerby GSS tests?
> >
> > I just checked the codes in MIT Kerberos. It was clear we should use
> > the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> > field in KdcReq is only used in AsReq, not used in TgsReq.
> > I will have a fix for this shortly.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Wednesday, April 22, 2015 7:37 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Thanks for your good progress and analysis. I’m not sure how KDC
> > would handle in such case, but a possibility is to use the client
> > principal name in the TGT ticket, would you inspect the fields of
> > the passed TGT and use the client field in it, when it’s null in the
> > KdcReq? I will check and make sure which way we should go later. Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 6:17 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok with the current code I've made some progress - I can now
> > successfully get a TGT from Kerby. However, I'm running into a
> > puzzling issue when trying to get a service key. Essentially, the
> > clientPrincipal in
> > KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> > This means that it just tries to retrieve the client Principal using
> > @realm, and this fails.
> > On the first TGT pass, the client + server principals in checkClient
> > look
> > like:
> >
> > Client PRINC: alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>
> > Client PRINC type: NT_PRINCIPAL
> > Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_SRV_INST
> > On the second call:
> >
> > Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> > Client PRINC type: NT_UNKNOWN
> > Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_UNKNOWN
> > The SName looks find. But the CName is missing. I know this code
> > works fine with the KDC in Apache Directory, so we must be doing
> > something odd with the parsing in Kerby.
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > I thought it’s good to have the following fix for now, as it
> > processes the enctypes list from client from first to end. I just
> > fired a follow-on issue to double check this.
> > https://issues.apache.org/jira/browse/DIRKRB-236
> >
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 8:53 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kiran,
> >
> > > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side
> > Is there any existing code in Apache Directory along these lines?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari
> > <kayyagari@apache.org <ma...@apache.org>> wrote:
> >
> >
> > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > Yes it’s a great fix! May be we could also update our related kdc
> > test to repeat the issue and guard the fix? In our existing tests,
> > the enctypes used in KrbClient are the same with the ones in
> > KdcServer side, so we don’t find the issue until now. Yes, client
> > may very likely request different enctypes that the KdcServer
> > doesn’t
> support/enable yet.
> >
> > yes, clients can send different enctypes depending the platform they
> > are running on.
> >
> > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side and then pick the best from the
> > ones requested by the client.
> > Thanks again.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:33 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I've found another bug. We are just picking the first desired
> > encryption type in KdcRequest.checkClient(). However, we may not
> > actually have this key. This leads to an NPE. Example:
> > We are requesting:
> >
> > aes256-cts-hmac-sha1-96 18
> > aes128-cts-hmac-sha1-96 17
> > des3-cbc-sha1 16
> > arcfour-hmac 23
> > des-cbc-crc 1
> > des-cbc-md5 3
> >
> > We pick the first one...however we only have the following keys stored:
> >
> > des3-cbc-sha1 16
> > aes128-cts-hmac-sha1-96 17
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 2165e17..e6bcef0 100644
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> > KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> > setClientEntry(clientEntry);
> >
> > - EncryptionType encType =
> > request.getReqBody().getEtypes().listIterator(
> > - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> > - setClientKey(clientKey);
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> > }
> >
> > protected void preauth() throws KrbException { Colm.
> >
> >
> > On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Yep I will do!
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, it looks like a good fix, 0 is there instead of null, for time
> fields
> > in kdc request. Would you double check other time values by the way?
> Thanks!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:11 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The problem above is that the "end time" is 0 instead of "null".
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 3d49af3..23275fc 100644
> > ---
> >
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > +++
> >
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> > }
> >
> > KerberosTime krbEndTime = request.getReqBody().getTill();
> > - if (krbEndTime == null) {
> > + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> > krbEndTime =
> > krbStartTime.extend(config.getMaximumTicketLifetime()
> > } else if (krbStartTime.greaterThan(krbEndTime)) {
> > throw new
> > KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> >
> > 2. Please disable preauth in KDC side or require preauth in client
> > side. Looks like client didn’t send preauth data but KDC required it.
> >
> > Ok I got a bit further by doing this. However, from what I can find
> > out, the GSS client code should be sending the Pre authentication
> > data (and there appears to be no option to disable it). So I think
> > there may be a
> bug
> > in how Kerby is processing the header? Should we log a JIRA to track
> this?
> > The error I now get (when disabling pre auth in Kerby) is:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
> later
> > than end time
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(K
> dcRequest.java:376)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:96)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > at
> >
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKd
> cHandler.java:51)
> > Any ideas? The Kerby server + CXF client are both on the same machine...
> > Colm.
> >
> >
> > If you don’t want to trouble with the config stuff, please just
> > change
> the
> > default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 6:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Actually I spoke too soon, I do know how to reproduce the
> > "pre-authentication" error. Simply uncomment the line
> > "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the
> > test. If
> I
> > put a printStackTrace in the NettyKdcServerImpl, I see:
> >
> > Error occured while processing request:Generic error (description in
> > e-text)
> > SocketTimeOutException with attempt: 2
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =3,
> > #bytes=169
> > Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger
> > info
> > INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id:
> > 0xbfe95a70,
> /
> > 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> > http://127.0.0.1:9002>]
> > org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> > (description in e-text)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRe
> quest.java:255)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:94)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> > Thanks for your response. I have a test-case of sorts that shows the
> > interop failure (although I can't reproduce the issue I reported
> yesterday
> > about the preauthentication data).
> >
> >
> >
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerbe
> ros-kerby
> > Run it with "mvn clean install". You may need the install the parent
> > module as well before running this, which is one level up.
> > The test sets up a Kerby server, and I have a @Ignore'd test using
> > Kerby client API to successfully communicate with it. Then I have a
> > Apache CXF-based test which uses the Kerberos functionality here
> > (based on GSS)
> to
> > get a service ticket. If I put printStackTrace in the
> > DefaultKdcHandler
> the
> > output looks like:
> >
> > Loaded from Java config
> > >>> KdcAccessibility: reset
> > >>> KdcAccessibility: reset
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > >>> KrbAsReq creating message
> > >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> > retries =3, #bytes=169
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =1,
> > #bytes=169
> > java.net.SocketTimeoutException: Read timed out
> > at java.net.SocketInputStream.socketRead0(Native Method)
> > at java.net.SocketInputStream.read(SocketInputStream.java:152)
> > at java.net.SocketInputStream.read(SocketInputStream.java:122)
> > at java.net.SocketInputStream.read(SocketInputStream.java:210)
> > at java.io.DataInputStream.readInt(DataInputStream.java:387)
> > at
> >
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessag
> e(KrbTcpTransport.java:54)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(Defau
> ltKdcHandler.java:46)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > >>>DEBUG: TCPClient could not read length field KrbKdcReq send:
> > >>>#bytes read=0
> > Any ideas?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > We haven’t any test for GSS client against Kerby yet, though we do
> > have tests in protocol level for ApReq (in kerb-core-test module).
> > We might
> look
> > at existing ApacheDS Kerberos codes to see if any such end to end
> > tests
> to
> > port.
> >
> > You’re right, current UDP support for KdcNetwork and NettyKdcNetwork
> > are to be done yet. I originally got them done some days ago, but
> > recently I was extremely busy with other projects, so kinds of
> > delayed. Sure JIRAs would be good to record them.
> >
> > For the issue you ran into, do you have test codes to repeat it, so
> > we
> may
> > have the chance to look at it? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Monday, April 20, 2015 10:40 PM
> > To: Apache Directory Developers List
> > Subject: Kerby GSS tests?
> >
> > Hi all,
> >
> > Are there any tests in the source (or has anyone successfully
> > tested) a Java GSS client -> Apache Kerby?
> > The first issue I ran into was that neither the KdcNetwork nor the
> > NettyKdcNetwork work with UDP. Is there a JIRA for this (or any
> > plans to fix it)?
> > I could work around the above by setting "udp_preference_limit = 1".
> > However, I then run into an issue where it fails due to no
> > pre-authentication data in the request. Are we sure that this
> > parsing is working correctly?
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
>> Will we also be supporting it for the Default case as opposed to the Netty case?
Sure, we will.
>> there is no validation of the service ticket. I will add this in
That's great. And also, based on this work, it would be possible to have another one in the SASL framework.
Regards,
Kai
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 29, 2015 8:50 PM
To: Zheng, Kai
Cc: kerby@directory.apache.org; Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Cool, I'll try out the UDP support. Will we also be supporting it for the Default case as opposed to the Netty case?
I'm not really sure if my test-case qualifies as an end-to-end test...there is no validation of the service ticket. I will add this in...
Colm.
On Wed, Apr 29, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Thanks Colm for the great work!
>
> Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
>
> By the way, Yaning made the UDP support happen for the NettyKdcNetwork
> today,
> https://issues.apache.org/jira/browse/DIRKRB-231
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 29, 2015 6:38 PM
> To: kerby@directory.apache.org
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Ok done!
>
> Repository: directory-kerby
> Updated Branches:
> refs/heads/master e452f1854 -> eb2e4c1ae
>
>
> Adding a GSS unit test
>
>
> Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
> Tree:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
> Diff:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
>
> Colm.
>
> On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> > Colm,
> >
> > Yes it’s a known issue due to incomplete implementation. When the
> > following one is resolved, I thought we could get back to this
> > verifying the function. I will hopefully work on it recently.
> > https://issues.apache.org/jira/browse/DIRKRB-235
> >
> > By the way, is it doable to port your end to end tests into Kerby,
> > without introducing the many deps? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, April 27, 2015 6:46 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Thanks, everything is working now :-) The remaining issue is that
> > the tests are failing when pre-auth is enabled. Do you want me to
> > start looking into this, or are there known issues here?
> > Colm.
> >
> > On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > It’s done now. The root cause is due to the incorrect TGS principal
> > construction. Please check out latest codes and also apply the
> > following change to your test project.
> >
> > Regards,
> > Kai
> >
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/authentication/AuthenticationTest.java
> > @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> > @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> > }
> >
> > @org.junit.Test
> > - @org.junit.Ignore
> > + //@org.junit.Ignore<ma...@org.junit.Ignore>
> > public void unitTest() throws Exception {
> > KrbClient client = new KrbClient();
> >
> > diff --git
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > b/apache/cxf/cxf-k
> > index 3806a70..802baa0 100644
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cx
> > f/ kerberos/jaxrs/JAXRSAuthenticationTest.java
> > @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREA
> > UT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRI
> NCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob =
> > "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Friday, April 24, 2015 8:12 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > So it’s another issue existing in client side, right? I checked our
> > today’s changes and found nothing related to the issue. It may be
> > not caused by the fix of previous issue.
> >
> > I can’t debug on your project due to maven module deps. I saw no
> > much difference from your test case with Kerby’s, but wonder why
> > it’s ok in Kerby project.
> > Will continue to investigate it tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, April 24, 2015 5:52 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Excellent thanks! However, now the unit test using the Kerby client
> > API fails :-) The problem is in getting the TGT. Using the GSS
> > client API, the value for the "PrincipalName principal =
> > request.getReqBody().getSname();" in
> > KdcRequest.checkServer() is:
> >
> > krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> > However, using the Kerby client API it's:
> >
> > krbtgt
> > and hence an error is thrown, as this principal is not stored. Any
> > ideas here? You can reproduce just by updating my github project,
> > and removing the @Ignore annotation from the "unitTest".
> > Colm.
> >
> > On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > It’s done! Below is my test running your test project. Please check
> > latest codes and verify it, thanks!
> >
> > >>>DEBUG: TCPClient reading 594 bytes KrbKdcReq send: #bytes
> > >>>read=594
> > >>> KdcAccessibility: remove localhost:9002
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> > http://service.ws.apache.org>
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > Using builtin default etypes for permitted_enctypes default etypes
> > for
> > permitted_enctypes: 18 17 16 23 1 3.
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > replay cache for alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org> is null.
> > object 0: 1429862199082/82299
> > >>> KrbApReq: authenticate succeed.
> > Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> > mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> > io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> > 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
> >
> > Results :
> >
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
> >
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] BUILD SUCCESS
> > [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [INFO] Total time: 6.770 s
> > [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> > 13M/262M [INFO]
> > --------------------------------------------------------------------
> > --
> > --
> > [drankye@zkdesk cxf-kerberos-kerby]$
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:31 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > There's no rush with any of this! I am just playing around with Kerby.
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, similar issue but this time is TransitedEncoding now. We need
> > to go thru the codes to make sure service ticket is correctly
> > filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:01 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok that looks good, the client is now working again, and I'm getting
> > past the decoding of the client name. Now there is another error on
> > the service side :-)
> >
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.
> java:76)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.j
> ava:133)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > This should fix the problem, but need some clean up. Will commit it
> > after your confirmation.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:50 PM
> >
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> > Subject: RE: Kerby GSS tests?
> >
> > Would you have a try with this? I will double check what’s the
> > correct way. Thanks.
> >
> > @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> > EncryptionType encryptionType = getEncryptionType();
> > EncryptionKey serverKey =
> > getServerEntry().getKeys().get(encryptionType
> >
> > - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> > + PrincipalName ticketPrincipal =
> > + request.getReqBody().getSname();
> >
> > EncTicketPart encTicketPart = new EncTicketPart();
> > KdcConfig config = kdcContext.getConfig();
> > (END)
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > It appears there is a regression in the fix, I'm now getting a
> > client
> > error:
> >
> > KrbException: Message stream modified (41)
> > at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> > at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> > at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> > at
> sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUti
> l.java:309)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Credent
> ialsUtil.java:115)
> > at
> > sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> > at
> > sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:
> > 17
> > 9)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm would you check the latest fix? Just committed, though I’m not
> > perfectly sure. It may has some other issues, but will check some
> > time later, when having tests in hand.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:10 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Yes you’re right. I’m working on a fix. Will let you know soon.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:09 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The first time we hit "issueTicket" the CName is correct "
> > alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> > However, on the second time it is blank. This sounds like a similar
> > bug that you fixed for when the cname was not in the request?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > >> So now my client is successfully communicating with Kerby!
> > It’s exciting! Thanks a lot.
> >
> > >>I'm getting an error in GSS when parsing the principal name
> > Looks like it failed to parse cname in encpart in the service ticket.
> > Would you debug into the issueTicket() in KdcRequest and check what
> > cname is set into the field?
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 6:43 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok I've figured out what the problem was. I was creating two
> > principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> > http://service.ws.apache.org>". The default value for the
> > TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> > the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>"
> > key was used first, and the other key was used for TGS. I solved it
> > by just specifying "krbtgt/
> > service.ws.apache.org<http://service.ws.apache.org>" as the
> TGS_PRINCIPAL in KdcConfig.
> > So now my client is successfully communicating with Kerby! However,
> > I'm now running into a problem on the service side. I'm getting an
> > error in GSS when parsing the principal name:
> >
> > Found KerberosKey for
> > bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> > at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at
> > sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > Any ideas?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > It may be caused by bad backend? What’s backend you used? I thought
> > two keys should be the same anyway.
> >
> > From: Zheng, Kai
> > Sent: Thursday, April 23, 2015 5:52 PM
> > To: 'coheigea@apache.org<ma...@apache.org>'
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Oh bad, looks like the key use to issue ticket isn’t the same one to
> > decrypt it in TgsRequest processing. The encryption type should be
> > the same, right, but then why we two different key values or keys?
> > Would you debug more? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 5:38 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > The two keys are not the same. They have the same encoding length +
> > kvno + tagno, but different byte[] content.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > It looks strange to me.
> > Would you debug and check the two keys are the same in that place
> > and the other place in KDC side KdcRequest:400:
> > EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> > serverKey, KeyUsage.KDC_REP_TICKET);
> >
> > Thanks. I’m going to sleep now. See you tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Wednesday, April 22, 2015 11:15 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I get the same error (decryption error) with this patch.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > The fix would be as follows. Would you verify and commit it if OK?
> Thanks.
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listItera
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > Ticket ticket = apReq.getTicket();
> > + EncryptionType encType =
> ticket.getEncryptedEncPart().getEType();
> > + EncryptionKey tgsKey =
> > + getTgsEntry().getKeys().get(encType);
> > if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> > }
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 10:46 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > >> Are we sure that the tgsKey above is the right key to decrpyt the
> > request?
> > Yes, the ticket there to decrypt is actually for TGS to interpret
> > and validate, a tgs key should be used. I’m still thinking about how
> > to get the encryption type right. It’s a certain one this time.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 10:01 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Looks good thanks! The next problem is an NPE in EncryptionHandler.
> > This is caused by a similar issue to before:
> >
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server/request/TgsRequest.java
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> > TgsRequest extends KdcRequest {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> > }
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listIterator().next();
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > + EncryptionKey tgsKey = null;
> > + for (EncryptionType encType :
> > getKdcReq().getReqBody().getEtypes()) {
> > + if (getTgsEntry().getKeys().containsKey(encType)) {
> > + tgsKey = getTgsEntry().getKeys().get(encType);
> > + break;
> > + }
> > + }
> > +
> > However, this patch results in the error:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> > decrypted field failed
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.
> java:116)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:160)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decry
> pt(AbstractEncTypeHandler.java:148)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(Encryp
> tionHandler.java:165)
> > at
> >
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(Encryption
> Util.java:132)
> > at
> > org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthe
> > nt
> > icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> > right key to decrpyt the request?
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > Would you check out the fix below and verify it? Thanks!
> >
> > commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> > Author: Drankye <dr...@gmail.com>>
> > Date: Wed Apr 22 21:25:21 2015 +0800
> >
> > Fixed the issue that cname field in KdcReqBody should not be
> > used in TgsReq
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 8:36 PM
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> >
> > Subject: RE: Kerby GSS tests?
> >
> > I just checked the codes in MIT Kerberos. It was clear we should use
> > the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> > field in KdcReq is only used in AsReq, not used in TgsReq.
> > I will have a fix for this shortly.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Wednesday, April 22, 2015 7:37 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Thanks for your good progress and analysis. I’m not sure how KDC
> > would handle in such case, but a possibility is to use the client
> > principal name in the TGT ticket, would you inspect the fields of
> > the passed TGT and use the client field in it, when it’s null in the
> > KdcReq? I will check and make sure which way we should go later. Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 6:17 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok with the current code I've made some progress - I can now
> > successfully get a TGT from Kerby. However, I'm running into a
> > puzzling issue when trying to get a service key. Essentially, the
> > clientPrincipal in
> > KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> > This means that it just tries to retrieve the client Principal using
> > @realm, and this fails.
> > On the first TGT pass, the client + server principals in checkClient
> > look
> > like:
> >
> > Client PRINC: alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>
> > Client PRINC type: NT_PRINCIPAL
> > Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_SRV_INST
> > On the second call:
> >
> > Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> > Client PRINC type: NT_UNKNOWN
> > Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_UNKNOWN
> > The SName looks find. But the CName is missing. I know this code
> > works fine with the KDC in Apache Directory, so we must be doing
> > something odd with the parsing in Kerby.
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > I thought it’s good to have the following fix for now, as it
> > processes the enctypes list from client from first to end. I just
> > fired a follow-on issue to double check this.
> > https://issues.apache.org/jira/browse/DIRKRB-236
> >
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 8:53 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kiran,
> >
> > > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side
> > Is there any existing code in Apache Directory along these lines?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari
> > <kayyagari@apache.org <ma...@apache.org>> wrote:
> >
> >
> > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > Yes it’s a great fix! May be we could also update our related kdc
> > test to repeat the issue and guard the fix? In our existing tests,
> > the enctypes used in KrbClient are the same with the ones in
> > KdcServer side, so we don’t find the issue until now. Yes, client
> > may very likely request different enctypes that the KdcServer
> > doesn’t
> support/enable yet.
> >
> > yes, clients can send different enctypes depending the platform they
> > are running on.
> >
> > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side and then pick the best from the
> > ones requested by the client.
> > Thanks again.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:33 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I've found another bug. We are just picking the first desired
> > encryption type in KdcRequest.checkClient(). However, we may not
> > actually have this key. This leads to an NPE. Example:
> > We are requesting:
> >
> > aes256-cts-hmac-sha1-96 18
> > aes128-cts-hmac-sha1-96 17
> > des3-cbc-sha1 16
> > arcfour-hmac 23
> > des-cbc-crc 1
> > des-cbc-md5 3
> >
> > We pick the first one...however we only have the following keys stored:
> >
> > des3-cbc-sha1 16
> > aes128-cts-hmac-sha1-96 17
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 2165e17..e6bcef0 100644
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/
> > server
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b/ server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> > KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> > setClientEntry(clientEntry);
> >
> > - EncryptionType encType =
> > request.getReqBody().getEtypes().listIterator(
> > - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> > - setClientKey(clientKey);
> > + for (EncryptionType encType :
> > + request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> > }
> >
> > protected void preauth() throws KrbException { Colm.
> >
> >
> > On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Yep I will do!
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, it looks like a good fix, 0 is there instead of null, for time
> fields
> > in kdc request. Would you double check other time values by the way?
> Thanks!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:11 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The problem above is that the "end time" is 0 instead of "null".
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/ker
> > b
> > index 3d49af3..23275fc 100644
> > ---
> >
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > +++
> >
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> > @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> > }
> >
> > KerberosTime krbEndTime = request.getReqBody().getTill();
> > - if (krbEndTime == null) {
> > + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> > krbEndTime =
> > krbStartTime.extend(config.getMaximumTicketLifetime()
> > } else if (krbStartTime.greaterThan(krbEndTime)) {
> > throw new
> > KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> >
> > 2. Please disable preauth in KDC side or require preauth in client
> > side. Looks like client didn’t send preauth data but KDC required it.
> >
> > Ok I got a bit further by doing this. However, from what I can find
> > out, the GSS client code should be sending the Pre authentication
> > data (and there appears to be no option to disable it). So I think
> > there may be a
> bug
> > in how Kerby is processing the header? Should we log a JIRA to track
> this?
> > The error I now get (when disabling pre auth in Kerby) is:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
> later
> > than end time
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(K
> dcRequest.java:376)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:96)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > at
> >
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKd
> cHandler.java:51)
> > Any ideas? The Kerby server + CXF client are both on the same machine...
> > Colm.
> >
> >
> > If you don’t want to trouble with the config stuff, please just
> > change
> the
> > default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 6:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Actually I spoke too soon, I do know how to reproduce the
> > "pre-authentication" error. Simply uncomment the line
> > "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the
> > test. If
> I
> > put a printStackTrace in the NettyKdcServerImpl, I see:
> >
> > Error occured while processing request:Generic error (description in
> > e-text)
> > SocketTimeOutException with attempt: 2
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =3,
> > #bytes=169
> > Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger
> > info
> > INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id:
> > 0xbfe95a70,
> /
> > 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> > http://127.0.0.1:9002>]
> > org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> > (description in e-text)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRe
> quest.java:255)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRe
> quest.java:94)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHand
> ler.java:77)
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> > Thanks for your response. I have a test-case of sorts that shows the
> > interop failure (although I can't reproduce the issue I reported
> yesterday
> > about the preauthentication data).
> >
> >
> >
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerbe
> ros-kerby
> > Run it with "mvn clean install". You may need the install the parent
> > module as well before running this, which is one level up.
> > The test sets up a Kerby server, and I have a @Ignore'd test using
> > Kerby client API to successfully communicate with it. Then I have a
> > Apache CXF-based test which uses the Kerberos functionality here
> > (based on GSS)
> to
> > get a service ticket. If I put printStackTrace in the
> > DefaultKdcHandler
> the
> > output looks like:
> >
> > Loaded from Java config
> > >>> KdcAccessibility: reset
> > >>> KdcAccessibility: reset
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > >>> KrbAsReq creating message
> > >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> > retries =3, #bytes=169
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt
> > >>> =1,
> > #bytes=169
> > java.net.SocketTimeoutException: Read timed out
> > at java.net.SocketInputStream.socketRead0(Native Method)
> > at java.net.SocketInputStream.read(SocketInputStream.java:152)
> > at java.net.SocketInputStream.read(SocketInputStream.java:122)
> > at java.net.SocketInputStream.read(SocketInputStream.java:210)
> > at java.io.DataInputStream.readInt(DataInputStream.java:387)
> > at
> >
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessag
> e(KrbTcpTransport.java:54)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(Defau
> ltKdcHandler.java:46)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > >>>DEBUG: TCPClient could not read length field KrbKdcReq send:
> > >>>#bytes read=0
> > Any ideas?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > We haven’t any test for GSS client against Kerby yet, though we do
> > have tests in protocol level for ApReq (in kerb-core-test module).
> > We might
> look
> > at existing ApacheDS Kerberos codes to see if any such end to end
> > tests
> to
> > port.
> >
> > You’re right, current UDP support for KdcNetwork and NettyKdcNetwork
> > are to be done yet. I originally got them done some days ago, but
> > recently I was extremely busy with other projects, so kinds of
> > delayed. Sure JIRAs would be good to record them.
> >
> > For the issue you ran into, do you have test codes to repeat it, so
> > we
> may
> > have the chance to look at it? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Monday, April 20, 2015 10:40 PM
> > To: Apache Directory Developers List
> > Subject: Kerby GSS tests?
> >
> > Hi all,
> >
> > Are there any tests in the source (or has anyone successfully
> > tested) a Java GSS client -> Apache Kerby?
> > The first issue I ran into was that neither the KdcNetwork nor the
> > NettyKdcNetwork work with UDP. Is there a JIRA for this (or any
> > plans to fix it)?
> > I could work around the above by setting "udp_preference_limit = 1".
> > However, I then run into an issue where it fails due to no
> > pre-authentication data in the request. Are we sure that this
> > parsing is working correctly?
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Cool, I'll try out the UDP support. Will we also be supporting it for the
Default case as opposed to the Netty case?
I'm not really sure if my test-case qualifies as an end-to-end test...there
is no validation of the service ticket. I will add this in...
Colm.
On Wed, Apr 29, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Thanks Colm for the great work!
>
> Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
>
> By the way, Yaning made the UDP support happen for the NettyKdcNetwork
> today,
> https://issues.apache.org/jira/browse/DIRKRB-231
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 29, 2015 6:38 PM
> To: kerby@directory.apache.org
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Ok done!
>
> Repository: directory-kerby
> Updated Branches:
> refs/heads/master e452f1854 -> eb2e4c1ae
>
>
> Adding a GSS unit test
>
>
> Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
> Tree: http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
> Diff: http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
>
> Colm.
>
> On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> > Colm,
> >
> > Yes it’s a known issue due to incomplete implementation. When the
> > following one is resolved, I thought we could get back to this
> > verifying the function. I will hopefully work on it recently.
> > https://issues.apache.org/jira/browse/DIRKRB-235
> >
> > By the way, is it doable to port your end to end tests into Kerby,
> > without introducing the many deps? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, April 27, 2015 6:46 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Thanks, everything is working now :-) The remaining issue is that the
> > tests are failing when pre-auth is enabled. Do you want me to start
> > looking into this, or are there known issues here?
> > Colm.
> >
> > On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > It’s done now. The root cause is due to the incorrect TGS principal
> > construction. Please check out latest codes and also apply the
> > following change to your test project.
> >
> > Regards,
> > Kai
> >
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/authentication/AuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/authentication/AuthenticationTest.java
> > @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob = "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> > @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> > }
> >
> > @org.junit.Test
> > - @org.junit.Ignore
> > + //@org.junit.Ignore<ma...@org.junit.Ignore>
> > public void unitTest() throws Exception {
> > KrbClient client = new KrbClient();
> >
> > diff --git
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/jaxrs/JAXRSAuthenticationTest.java
> > b/apache/cxf/cxf-k
> > index 3806a70..802baa0 100644
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/jaxrs/JAXRSAuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/jaxrs/JAXRSAuthenticationTest.java
> > @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob = "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Friday, April 24, 2015 8:12 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > So it’s another issue existing in client side, right? I checked our
> > today’s changes and found nothing related to the issue. It may be not
> > caused by the fix of previous issue.
> >
> > I can’t debug on your project due to maven module deps. I saw no much
> > difference from your test case with Kerby’s, but wonder why it’s ok in
> > Kerby project.
> > Will continue to investigate it tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, April 24, 2015 5:52 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Excellent thanks! However, now the unit test using the Kerby client
> > API fails :-) The problem is in getting the TGT. Using the GSS client
> > API, the value for the "PrincipalName principal =
> > request.getReqBody().getSname();" in
> > KdcRequest.checkServer() is:
> >
> > krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> > However, using the Kerby client API it's:
> >
> > krbtgt
> > and hence an error is thrown, as this principal is not stored. Any
> > ideas here? You can reproduce just by updating my github project, and
> > removing the @Ignore annotation from the "unitTest".
> > Colm.
> >
> > On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > It’s done! Below is my test running your test project. Please check
> > latest codes and verify it, thanks!
> >
> > >>>DEBUG: TCPClient reading 594 bytes
> > >>> KrbKdcReq send: #bytes read=594
> > >>> KdcAccessibility: remove localhost:9002
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> > http://service.ws.apache.org>
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > Using builtin default etypes for permitted_enctypes default etypes for
> > permitted_enctypes: 18 17 16 23 1 3.
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > replay cache for alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org> is null.
> > object 0: 1429862199082/82299
> > >>> KrbApReq: authenticate succeed.
> > Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> > mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> > io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> > 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
> >
> > Results :
> >
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
> >
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] Total time: 6.770 s
> > [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> > 13M/262M [INFO]
> > ----------------------------------------------------------------------
> > --
> > [drankye@zkdesk cxf-kerberos-kerby]$
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:31 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > There's no rush with any of this! I am just playing around with Kerby.
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, similar issue but this time is TransitedEncoding now. We need to
> > go thru the codes to make sure service ticket is correctly filled. I
> > will look at it tomorrow, kinds of tired now. Thanks for your patience!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:01 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok that looks good, the client is now working again, and I'm getting
> > past the decoding of the client name. Now there is another error on
> > the service side :-)
> >
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > This should fix the problem, but need some clean up. Will commit it
> > after your confirmation.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:50 PM
> >
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> > Subject: RE: Kerby GSS tests?
> >
> > Would you have a try with this? I will double check what’s the correct
> > way. Thanks.
> >
> > @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> > EncryptionType encryptionType = getEncryptionType();
> > EncryptionKey serverKey =
> > getServerEntry().getKeys().get(encryptionType
> >
> > - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> > + PrincipalName ticketPrincipal =
> > + request.getReqBody().getSname();
> >
> > EncTicketPart encTicketPart = new EncTicketPart();
> > KdcConfig config = kdcContext.getConfig();
> > (END)
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > It appears there is a regression in the fix, I'm now getting a client
> > error:
> >
> > KrbException: Message stream modified (41)
> > at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> > at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> > at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> > at
> sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> > at
> > sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> > at
> > sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:17
> > 9)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm would you check the latest fix? Just committed, though I’m not
> > perfectly sure. It may has some other issues, but will check some time
> > later, when having tests in hand.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:10 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Yes you’re right. I’m working on a fix. Will let you know soon.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:09 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The first time we hit "issueTicket" the CName is correct "
> > alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> > However, on the second time it is blank. This sounds like a similar
> > bug that you fixed for when the cname was not in the request?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > >> So now my client is successfully communicating with Kerby!
> > It’s exciting! Thanks a lot.
> >
> > >>I'm getting an error in GSS when parsing the principal name
> > Looks like it failed to parse cname in encpart in the service ticket.
> > Would you debug into the issueTicket() in KdcRequest and check what
> > cname is set into the field?
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 6:43 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok I've figured out what the problem was. I was creating two
> > principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> > http://service.ws.apache.org>". The default value for the
> > TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> > the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>" key
> > was used first, and the other key was used for TGS. I solved it by
> > just specifying "krbtgt/
> > service.ws.apache.org<http://service.ws.apache.org>" as the
> TGS_PRINCIPAL in KdcConfig.
> > So now my client is successfully communicating with Kerby! However,
> > I'm now running into a problem on the service side. I'm getting an
> > error in GSS when parsing the principal name:
> >
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> > at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > Any ideas?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > It may be caused by bad backend? What’s backend you used? I thought
> > two keys should be the same anyway.
> >
> > From: Zheng, Kai
> > Sent: Thursday, April 23, 2015 5:52 PM
> > To: 'coheigea@apache.org<ma...@apache.org>'
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Oh bad, looks like the key use to issue ticket isn’t the same one to
> > decrypt it in TgsRequest processing. The encryption type should be the
> > same, right, but then why we two different key values or keys?
> > Would you debug more? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 5:38 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > The two keys are not the same. They have the same encoding length +
> > kvno + tagno, but different byte[] content.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > It looks strange to me.
> > Would you debug and check the two keys are the same in that place and
> > the other place in KDC side KdcRequest:400:
> > EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> > serverKey, KeyUsage.KDC_REP_TICKET);
> >
> > Thanks. I’m going to sleep now. See you tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Wednesday, April 22, 2015 11:15 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I get the same error (decryption error) with this patch.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > The fix would be as follows. Would you verify and commit it if OK?
> Thanks.
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listItera
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > Ticket ticket = apReq.getTicket();
> > + EncryptionType encType =
> ticket.getEncryptedEncPart().getEType();
> > + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> > }
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 10:46 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > >> Are we sure that the tgsKey above is the right key to decrpyt the
> > request?
> > Yes, the ticket there to decrypt is actually for TGS to interpret and
> > validate, a tgs key should be used. I’m still thinking about how to
> > get the encryption type right. It’s a certain one this time.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 10:01 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Looks good thanks! The next problem is an NPE in EncryptionHandler.
> > This is caused by a similar issue to before:
> >
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server/request/TgsRequest.java
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> > TgsRequest extends KdcRequest {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> > }
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listIterator().next();
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > + EncryptionKey tgsKey = null;
> > + for (EncryptionType encType :
> > getKdcReq().getReqBody().getEtypes()) {
> > + if (getTgsEntry().getKeys().containsKey(encType)) {
> > + tgsKey = getTgsEntry().getKeys().get(encType);
> > + break;
> > + }
> > + }
> > +
> > However, this patch results in the error:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> > decrypted field failed
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> > at
> >
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> > at
> > org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthent
> > icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> > right key to decrpyt the request?
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > Would you check out the fix below and verify it? Thanks!
> >
> > commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> > Author: Drankye <dr...@gmail.com>>
> > Date: Wed Apr 22 21:25:21 2015 +0800
> >
> > Fixed the issue that cname field in KdcReqBody should not be used
> > in TgsReq
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 8:36 PM
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> >
> > Subject: RE: Kerby GSS tests?
> >
> > I just checked the codes in MIT Kerberos. It was clear we should use
> > the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> > field in KdcReq is only used in AsReq, not used in TgsReq.
> > I will have a fix for this shortly.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Wednesday, April 22, 2015 7:37 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Thanks for your good progress and analysis. I’m not sure how KDC would
> > handle in such case, but a possibility is to use the client principal
> > name in the TGT ticket, would you inspect the fields of the passed TGT
> > and use the client field in it, when it’s null in the KdcReq? I will
> > check and make sure which way we should go later. Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 6:17 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok with the current code I've made some progress - I can now
> > successfully get a TGT from Kerby. However, I'm running into a
> > puzzling issue when trying to get a service key. Essentially, the
> > clientPrincipal in
> > KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> > This means that it just tries to retrieve the client Principal using
> > @realm, and this fails.
> > On the first TGT pass, the client + server principals in checkClient
> > look
> > like:
> >
> > Client PRINC: alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>
> > Client PRINC type: NT_PRINCIPAL
> > Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_SRV_INST
> > On the second call:
> >
> > Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> > Client PRINC type: NT_UNKNOWN
> > Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_UNKNOWN
> > The SName looks find. But the CName is missing. I know this code works
> > fine with the KDC in Apache Directory, so we must be doing something
> > odd with the parsing in Kerby.
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > I thought it’s good to have the following fix for now, as it processes
> > the enctypes list from client from first to end. I just fired a
> > follow-on issue to double check this.
> > https://issues.apache.org/jira/browse/DIRKRB-236
> >
> > + for (EncryptionType encType : request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 8:53 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kiran,
> >
> > > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side
> > Is there any existing code in Apache Directory along these lines?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <kayyagari@apache.org
> > <ma...@apache.org>> wrote:
> >
> >
> > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > Yes it’s a great fix! May be we could also update our related kdc test
> > to repeat the issue and guard the fix? In our existing tests, the
> > enctypes used in KrbClient are the same with the ones in KdcServer
> > side, so we don’t find the issue until now. Yes, client may very
> > likely request different enctypes that the KdcServer doesn’t
> support/enable yet.
> >
> > yes, clients can send different enctypes depending the platform they
> > are running on.
> >
> > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side and then pick the best from the
> > ones requested by the client.
> > Thanks again.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:33 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I've found another bug. We are just picking the first desired
> > encryption type in KdcRequest.checkClient(). However, we may not
> > actually have this key. This leads to an NPE. Example:
> > We are requesting:
> >
> > aes256-cts-hmac-sha1-96 18
> > aes128-cts-hmac-sha1-96 17
> > des3-cbc-sha1 16
> > arcfour-hmac 23
> > des-cbc-crc 1
> > des-cbc-md5 3
> >
> > We pick the first one...however we only have the following keys stored:
> >
> > des3-cbc-sha1 16
> > aes128-cts-hmac-sha1-96 17
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> > index 2165e17..e6bcef0 100644
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> > KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> > setClientEntry(clientEntry);
> >
> > - EncryptionType encType =
> > request.getReqBody().getEtypes().listIterator(
> > - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> > - setClientKey(clientKey);
> > + for (EncryptionType encType : request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> > }
> >
> > protected void preauth() throws KrbException { Colm.
> >
> >
> > On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Yep I will do!
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, it looks like a good fix, 0 is there instead of null, for time
> fields
> > in kdc request. Would you double check other time values by the way?
> Thanks!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:11 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The problem above is that the "end time" is 0 instead of "null". What do
> > you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> > index 3d49af3..23275fc 100644
> > ---
> >
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> > +++
> >
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> > @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> > }
> >
> > KerberosTime krbEndTime = request.getReqBody().getTill();
> > - if (krbEndTime == null) {
> > + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> > krbEndTime =
> > krbStartTime.extend(config.getMaximumTicketLifetime()
> > } else if (krbStartTime.greaterThan(krbEndTime)) {
> > throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> >
> > 2. Please disable preauth in KDC side or require preauth in client
> > side. Looks like client didn’t send preauth data but KDC required it.
> >
> > Ok I got a bit further by doing this. However, from what I can find out,
> > the GSS client code should be sending the Pre authentication data (and
> > there appears to be no option to disable it). So I think there may be a
> bug
> > in how Kerby is processing the header? Should we log a JIRA to track
> this?
> > The error I now get (when disabling pre auth in Kerby) is:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
> later
> > than end time
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> > at
> >
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
> > Any ideas? The Kerby server + CXF client are both on the same machine...
> > Colm.
> >
> >
> > If you don’t want to trouble with the config stuff, please just change
> the
> > default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 6:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Actually I spoke too soon, I do know how to reproduce the
> > "pre-authentication" error. Simply uncomment the line
> > "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If
> I
> > put a printStackTrace in the NettyKdcServerImpl, I see:
> >
> > Error occured while processing request:Generic error (description in
> > e-text)
> > SocketTimeOutException with attempt: 2
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> > #bytes=169
> > Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70,
> /
> > 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> > http://127.0.0.1:9002>]
> > org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> > (description in e-text)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> > Thanks for your response. I have a test-case of sorts that shows the
> > interop failure (although I can't reproduce the issue I reported
> yesterday
> > about the preauthentication data).
> >
> >
> >
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
> > Run it with "mvn clean install". You may need the install the parent
> > module as well before running this, which is one level up.
> > The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> > client API to successfully communicate with it. Then I have a Apache
> > CXF-based test which uses the Kerberos functionality here (based on GSS)
> to
> > get a service ticket. If I put printStackTrace in the DefaultKdcHandler
> the
> > output looks like:
> >
> > Loaded from Java config
> > >>> KdcAccessibility: reset
> > >>> KdcAccessibility: reset
> > Using builtin default etypes for default_tkt_enctypes
> > default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> > >>> KrbAsReq creating message
> > >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> > retries =3, #bytes=169
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> > #bytes=169
> > java.net.SocketTimeoutException: Read timed out
> > at java.net.SocketInputStream.socketRead0(Native Method)
> > at java.net.SocketInputStream.read(SocketInputStream.java:152)
> > at java.net.SocketInputStream.read(SocketInputStream.java:122)
> > at java.net.SocketInputStream.read(SocketInputStream.java:210)
> > at java.io.DataInputStream.readInt(DataInputStream.java:387)
> > at
> >
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > >>>DEBUG: TCPClient could not read length field
> > >>> KrbKdcReq send: #bytes read=0
> > Any ideas?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > We haven’t any test for GSS client against Kerby yet, though we do have
> > tests in protocol level for ApReq (in kerb-core-test module). We might
> look
> > at existing ApacheDS Kerberos codes to see if any such end to end tests
> to
> > port.
> >
> > You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> > to be done yet. I originally got them done some days ago, but recently I
> > was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> > would be good to record them.
> >
> > For the issue you ran into, do you have test codes to repeat it, so we
> may
> > have the chance to look at it? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Monday, April 20, 2015 10:40 PM
> > To: Apache Directory Developers List
> > Subject: Kerby GSS tests?
> >
> > Hi all,
> >
> > Are there any tests in the source (or has anyone successfully tested) a
> > Java GSS client -> Apache Kerby?
> > The first issue I ran into was that neither the KdcNetwork nor the
> > NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> > fix it)?
> > I could work around the above by setting "udp_preference_limit = 1".
> > However, I then run into an issue where it fails due to no
> > pre-authentication data in the request. Are we sure that this parsing is
> > working correctly?
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Cool, I'll try out the UDP support. Will we also be supporting it for the
Default case as opposed to the Netty case?
I'm not really sure if my test-case qualifies as an end-to-end test...there
is no validation of the service ticket. I will add this in...
Colm.
On Wed, Apr 29, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Thanks Colm for the great work!
>
> Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
>
> By the way, Yaning made the UDP support happen for the NettyKdcNetwork
> today,
> https://issues.apache.org/jira/browse/DIRKRB-231
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 29, 2015 6:38 PM
> To: kerby@directory.apache.org
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Ok done!
>
> Repository: directory-kerby
> Updated Branches:
> refs/heads/master e452f1854 -> eb2e4c1ae
>
>
> Adding a GSS unit test
>
>
> Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
> Tree: http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
> Diff: http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
>
> Colm.
>
> On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> > Colm,
> >
> > Yes it’s a known issue due to incomplete implementation. When the
> > following one is resolved, I thought we could get back to this
> > verifying the function. I will hopefully work on it recently.
> > https://issues.apache.org/jira/browse/DIRKRB-235
> >
> > By the way, is it doable to port your end to end tests into Kerby,
> > without introducing the many deps? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Monday, April 27, 2015 6:46 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Thanks, everything is working now :-) The remaining issue is that the
> > tests are failing when pre-auth is enabled. Do you want me to start
> > looking into this, or are there known issues here?
> > Colm.
> >
> > On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > It’s done now. The root cause is due to the incorrect TGS principal
> > construction. Please check out latest codes and also apply the
> > following change to your test project.
> >
> > Regards,
> > Kai
> >
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/authentication/AuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/authentication/AuthenticationTest.java
> > @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob = "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> > @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> > org.junit.Assert {
> > }
> >
> > @org.junit.Test
> > - @org.junit.Ignore
> > + //@org.junit.Ignore<ma...@org.junit.Ignore>
> > public void unitTest() throws Exception {
> > KrbClient client = new KrbClient();
> >
> > diff --git
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/jaxrs/JAXRSAuthenticationTest.java
> > b/apache/cxf/cxf-k
> > index 3806a70..802baa0 100644
> > ---
> > a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/jaxrs/JAXRSAuthenticationTest.java
> > +++
> > b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> > kerberos/jaxrs/JAXRSAuthenticationTest.java
> > @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> > org.junit.Assert {
> >
> > // Need to disable PRE_AUTH (not sure why, maybe a bug in
> > Kerby)
> >
> >
> > kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> > H_REQUIRED,
> > false);
> > -
> >
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> > - "krbtgt/
> > service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>");
> > -
> > +
> > // Create principals
> > String alice = "alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>";
> > String bob = "bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>";
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Friday, April 24, 2015 8:12 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > So it’s another issue existing in client side, right? I checked our
> > today’s changes and found nothing related to the issue. It may be not
> > caused by the fix of previous issue.
> >
> > I can’t debug on your project due to maven module deps. I saw no much
> > difference from your test case with Kerby’s, but wonder why it’s ok in
> > Kerby project.
> > Will continue to investigate it tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Friday, April 24, 2015 5:52 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Excellent thanks! However, now the unit test using the Kerby client
> > API fails :-) The problem is in getting the TGT. Using the GSS client
> > API, the value for the "PrincipalName principal =
> > request.getReqBody().getSname();" in
> > KdcRequest.checkServer() is:
> >
> > krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> > However, using the Kerby client API it's:
> >
> > krbtgt
> > and hence an error is thrown, as this principal is not stored. Any
> > ideas here? You can reproduce just by updating my github project, and
> > removing the @Ignore annotation from the "unitTest".
> > Colm.
> >
> > On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > It’s done! Below is my test running your test project. Please check
> > latest codes and verify it, thanks!
> >
> > >>>DEBUG: TCPClient reading 594 bytes
> > >>> KrbKdcReq send: #bytes read=594
> > >>> KdcAccessibility: remove localhost:9002
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> > http://service.ws.apache.org>
> > Using builtin default etypes for default_tkt_enctypes default etypes
> > for default_tkt_enctypes: 18 17 16 23 1 3.
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > Using builtin default etypes for permitted_enctypes default etypes for
> > permitted_enctypes: 18 17 16 23 1 3.
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > replay cache for alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org> is null.
> > object 0: 1429862199082/82299
> > >>> KrbApReq: authenticate succeed.
> > Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> > mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> > io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> > 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
> >
> > Results :
> >
> > Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
> >
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] Total time: 6.770 s
> > [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> > 13M/262M [INFO]
> > ----------------------------------------------------------------------
> > --
> > [drankye@zkdesk cxf-kerberos-kerby]$
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:31 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > There's no rush with any of this! I am just playing around with Kerby.
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, similar issue but this time is TransitedEncoding now. We need to
> > go thru the codes to make sure service ticket is correctly filled. I
> > will look at it tomorrow, kinds of tired now. Thanks for your patience!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 9:01 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok that looks good, the client is now working again, and I'm getting
> > past the decoding of the client name. Now there is another error on
> > the service side :-)
> >
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> > at
> >
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > This should fix the problem, but need some clean up. Will commit it
> > after your confirmation.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:50 PM
> >
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> > Subject: RE: Kerby GSS tests?
> >
> > Would you have a try with this? I will double check what’s the correct
> > way. Thanks.
> >
> > @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> > EncryptionType encryptionType = getEncryptionType();
> > EncryptionKey serverKey =
> > getServerEntry().getKeys().get(encryptionType
> >
> > - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> > + PrincipalName ticketPrincipal =
> > + request.getReqBody().getSname();
> >
> > EncTicketPart encTicketPart = new EncTicketPart();
> > KdcConfig config = kdcContext.getConfig();
> > (END)
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > It appears there is a regression in the fix, I'm now getting a client
> > error:
> >
> > KrbException: Message stream modified (41)
> > at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> > at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> > at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> > at
> sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> > at
> >
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> > at
> > sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> > at
> > sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> > at
> > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:17
> > 9)
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm would you check the latest fix? Just committed, though I’m not
> > perfectly sure. It may has some other issues, but will check some time
> > later, when having tests in hand.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Thursday, April 23, 2015 7:10 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Yes you’re right. I’m working on a fix. Will let you know soon.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 7:09 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The first time we hit "issueTicket" the CName is correct "
> > alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> > However, on the second time it is blank. This sounds like a similar
> > bug that you fixed for when the cname was not in the request?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > >> So now my client is successfully communicating with Kerby!
> > It’s exciting! Thanks a lot.
> >
> > >>I'm getting an error in GSS when parsing the principal name
> > Looks like it failed to parse cname in encpart in the service ticket.
> > Would you debug into the issueTicket() in KdcRequest and check what
> > cname is set into the field?
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Thursday, April 23, 2015 6:43 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok I've figured out what the problem was. I was creating two
> > principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> > http://service.ws.apache.org>". The default value for the
> > TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> > the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>" key
> > was used first, and the other key was used for TGS. I solved it by
> > just specifying "krbtgt/
> > service.ws.apache.org<http://service.ws.apache.org>" as the
> TGS_PRINCIPAL in KdcConfig.
> > So now my client is successfully communicating with Kerby! However,
> > I'm now running into a problem on the service side. I'm getting an
> > error in GSS when parsing the principal name:
> >
> > Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> > <ma...@service.ws.apache.org>
> > Entered Krb5Context.acceptSecContext with state=STATE_NEW
> > >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> > java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> > at
> > sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> > at sun.security.util.DerValue.<init>(DerValue.java:252)
> > at
> > sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> > at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> > at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> > at
> > sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> > at
> > sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> > at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> > Any ideas?
> > Colm.
> >
> > On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > It may be caused by bad backend? What’s backend you used? I thought
> > two keys should be the same anyway.
> >
> > From: Zheng, Kai
> > Sent: Thursday, April 23, 2015 5:52 PM
> > To: 'coheigea@apache.org<ma...@apache.org>'
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Oh bad, looks like the key use to issue ticket isn’t the same one to
> > decrypt it in TgsRequest processing. The encryption type should be the
> > same, right, but then why we two different key values or keys?
> > Would you debug more? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Thursday, April 23, 2015 5:38 PM
> >
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > The two keys are not the same. They have the same encoding length +
> > kvno + tagno, but different byte[] content.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > It looks strange to me.
> > Would you debug and check the two keys are the same in that place and
> > the other place in KDC side KdcRequest:400:
> > EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> > serverKey, KeyUsage.KDC_REP_TICKET);
> >
> > Thanks. I’m going to sleep now. See you tomorrow.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Wednesday, April 22, 2015 11:15 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I get the same error (decryption error) with this patch.
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > The fix would be as follows. Would you verify and commit it if OK?
> Thanks.
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listItera
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > Ticket ticket = apReq.getTicket();
> > + EncryptionType encType =
> ticket.getEncryptedEncPart().getEType();
> > + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> > }
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 10:46 PM
> >
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > >> Are we sure that the tgsKey above is the right key to decrpyt the
> > request?
> > Yes, the ticket there to decrypt is actually for TGS to interpret and
> > validate, a tgs key should be used. I’m still thinking about how to
> > get the encryption type right. It’s a certain one this time.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 10:01 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Looks good thanks! The next problem is an NPE in EncryptionHandler.
> > This is caused by a similar issue to before:
> >
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server/request/TgsRequest.java
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> > TgsRequest extends KdcRequest {
> > throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> > }
> >
> > - EncryptionType encType =
> > getKdcReq().getReqBody().getEtypes().listIterator().next();
> > - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> > -
> > + EncryptionKey tgsKey = null;
> > + for (EncryptionType encType :
> > getKdcReq().getReqBody().getEtypes()) {
> > + if (getTgsEntry().getKeys().containsKey(encType)) {
> > + tgsKey = getTgsEntry().getKeys().get(encType);
> > + break;
> > + }
> > + }
> > +
> > However, this patch results in the error:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> > decrypted field failed
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> > at
> >
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> > at
> >
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> > at
> > org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthent
> > icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> > right key to decrpyt the request?
> > Colm.
> >
> > On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Colm,
> >
> > Would you check out the fix below and verify it? Thanks!
> >
> > commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> > Author: Drankye <dr...@gmail.com>>
> > Date: Wed Apr 22 21:25:21 2015 +0800
> >
> > Fixed the issue that cname field in KdcReqBody should not be used
> > in TgsReq
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai
> > [mailto:kai.zheng@intel.com<ma...@intel.com>]
> > Sent: Wednesday, April 22, 2015 8:36 PM
> > To: Apache Directory Developers List; coheigea@apache.org<mailto:
> > coheigea@apache.org>
> >
> > Subject: RE: Kerby GSS tests?
> >
> > I just checked the codes in MIT Kerberos. It was clear we should use
> > the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> > field in KdcReq is only used in AsReq, not used in TgsReq.
> > I will have a fix for this shortly.
> >
> > Regards,
> > Kai
> >
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Wednesday, April 22, 2015 7:37 PM
> > To: coheigea@apache.org<ma...@apache.org>
> > Cc: Apache Directory Developers List
> > Subject: RE: Kerby GSS tests?
> >
> > Hi Colm,
> >
> > Thanks for your good progress and analysis. I’m not sure how KDC would
> > handle in such case, but a possibility is to use the client principal
> > name in the TGT ticket, would you inspect the fields of the passed TGT
> > and use the client field in it, when it’s null in the KdcReq? I will
> > check and make sure which way we should go later. Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> > Sent: Wednesday, April 22, 2015 6:17 PM
> > To: Zheng, Kai
> > Cc: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > Ok with the current code I've made some progress - I can now
> > successfully get a TGT from Kerby. However, I'm running into a
> > puzzling issue when trying to get a service key. Essentially, the
> > clientPrincipal in
> > KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> > This means that it just tries to retrieve the client Principal using
> > @realm, and this fails.
> > On the first TGT pass, the client + server principals in checkClient
> > look
> > like:
> >
> > Client PRINC: alice@service.ws.apache.org<mailto:
> > alice@service.ws.apache.org>
> > Client PRINC type: NT_PRINCIPAL
> > Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_SRV_INST
> > On the second call:
> >
> > Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> > Client PRINC type: NT_UNKNOWN
> > Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> > service.ws.apache.org@service.ws.apache.org>
> > Server PRINC type: NT_UNKNOWN
> > The SName looks find. But the CName is missing. I know this code works
> > fine with the KDC in Apache Directory, so we must be doing something
> > odd with the parsing in Kerby.
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > I thought it’s good to have the following fix for now, as it processes
> > the enctypes list from client from first to end. I just fired a
> > follow-on issue to double check this.
> > https://issues.apache.org/jira/browse/DIRKRB-236
> >
> > + for (EncryptionType encType : request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 8:53 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kiran,
> >
> > > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side
> > Is there any existing code in Apache Directory along these lines?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <kayyagari@apache.org
> > <ma...@apache.org>> wrote:
> >
> >
> > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > Yes it’s a great fix! May be we could also update our related kdc test
> > to repeat the issue and guard the fix? In our existing tests, the
> > enctypes used in KrbClient are the same with the ones in KdcServer
> > side, so we don’t find the issue until now. Yes, client may very
> > likely request different enctypes that the KdcServer doesn’t
> support/enable yet.
> >
> > yes, clients can send different enctypes depending the platform they
> > are running on.
> >
> > The enctypes should always be sorted from the most to least
> > strong/preferred on the server side and then pick the best from the
> > ones requested by the client.
> > Thanks again.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:33 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Hi Kai,
> > I've found another bug. We are just picking the first desired
> > encryption type in KdcRequest.checkClient(). However, we may not
> > actually have this key. This leads to an NPE. Example:
> > We are requesting:
> >
> > aes256-cts-hmac-sha1-96 18
> > aes128-cts-hmac-sha1-96 17
> > des3-cbc-sha1 16
> > arcfour-hmac 23
> > des-cbc-crc 1
> > des-cbc-md5 3
> >
> > We pick the first one...however we only have the following keys stored:
> >
> > des3-cbc-sha1 16
> > aes128-cts-hmac-sha1-96 17
> > What do you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> > index 2165e17..e6bcef0 100644
> > ---
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server
> > +++
> > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> > server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> > KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> > setClientEntry(clientEntry);
> >
> > - EncryptionType encType =
> > request.getReqBody().getEtypes().listIterator(
> > - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> > - setClientKey(clientKey);
> > + for (EncryptionType encType : request.getReqBody().getEtypes())
> {
> > + if (clientEntry.getKeys().containsKey(encType)) {
> > + EncryptionKey clientKey =
> > clientEntry.getKeys().get(encType);
> > + setClientKey(clientKey);
> > + break;
> > + }
> > + }
> > }
> >
> > protected void preauth() throws KrbException { Colm.
> >
> >
> > On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> >
> > Yep I will do!
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Yes, it looks like a good fix, 0 is there instead of null, for time
> fields
> > in kdc request. Would you double check other time values by the way?
> Thanks!
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 7:11 PM
> >
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> >
> > The problem above is that the "end time" is 0 instead of "null". What do
> > you think of this patch?
> >
> > diff --git
> > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> > index 3d49af3..23275fc 100644
> > ---
> >
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> > +++
> >
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> > @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> > }
> >
> > KerberosTime krbEndTime = request.getReqBody().getTill();
> > - if (krbEndTime == null) {
> > + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> > krbEndTime =
> > krbStartTime.extend(config.getMaximumTicketLifetime()
> > } else if (krbStartTime.greaterThan(krbEndTime)) {
> > throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> >
> > 2. Please disable preauth in KDC side or require preauth in client
> > side. Looks like client didn’t send preauth data but KDC required it.
> >
> > Ok I got a bit further by doing this. However, from what I can find out,
> > the GSS client code should be sending the Pre authentication data (and
> > there appears to be no option to disable it). So I think there may be a
> bug
> > in how Kerby is processing the header? Should we log a JIRA to track
> this?
> > The error I now get (when disabling pre auth in Kerby) is:
> >
> > org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
> later
> > than end time
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> > at
> >
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
> > Any ideas? The Kerby server + CXF client are both on the same machine...
> > Colm.
> >
> >
> > If you don’t want to trouble with the config stuff, please just change
> the
> > default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Tuesday, April 21, 2015 6:34 PM
> > To: Apache Directory Developers List
> > Subject: Re: Kerby GSS tests?
> >
> > Actually I spoke too soon, I do know how to reproduce the
> > "pre-authentication" error. Simply uncomment the line
> > "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If
> I
> > put a printStackTrace in the NettyKdcServerImpl, I see:
> >
> > Error occured while processing request:Generic error (description in
> > e-text)
> > SocketTimeOutException with attempt: 2
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> > #bytes=169
> > Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> > INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70,
> /
> > 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> > http://127.0.0.1:9002>]
> > org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> > (description in e-text)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
> coheigea@apache.org
> > <ma...@apache.org>> wrote:
> > Hi Kai,
> > Thanks for your response. I have a test-case of sorts that shows the
> > interop failure (although I can't reproduce the issue I reported
> yesterday
> > about the preauthentication data).
> >
> >
> >
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
> > Run it with "mvn clean install". You may need the install the parent
> > module as well before running this, which is one level up.
> > The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> > client API to successfully communicate with it. Then I have a Apache
> > CXF-based test which uses the Kerberos functionality here (based on GSS)
> to
> > get a service ticket. If I put printStackTrace in the DefaultKdcHandler
> the
> > output looks like:
> >
> > Loaded from Java config
> > >>> KdcAccessibility: reset
> > >>> KdcAccessibility: reset
> > Using builtin default etypes for default_tkt_enctypes
> > default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> > >>> KrbAsReq creating message
> > >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> > retries =3, #bytes=169
> > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> > #bytes=169
> > java.net.SocketTimeoutException: Read timed out
> > at java.net.SocketInputStream.socketRead0(Native Method)
> > at java.net.SocketInputStream.read(SocketInputStream.java:152)
> > at java.net.SocketInputStream.read(SocketInputStream.java:122)
> > at java.net.SocketInputStream.read(SocketInputStream.java:210)
> > at java.io.DataInputStream.readInt(DataInputStream.java:387)
> > at
> >
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> > at
> >
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > >>>DEBUG: TCPClient could not read length field
> > >>> KrbKdcReq send: #bytes read=0
> > Any ideas?
> > Colm.
> >
> > On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com
> <mailto:
> > kai.zheng@intel.com>> wrote:
> > Hi Colm,
> >
> > We haven’t any test for GSS client against Kerby yet, though we do have
> > tests in protocol level for ApReq (in kerb-core-test module). We might
> look
> > at existing ApacheDS Kerberos codes to see if any such end to end tests
> to
> > port.
> >
> > You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> > to be done yet. I originally got them done some days ago, but recently I
> > was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> > would be good to record them.
> >
> > For the issue you ran into, do you have test codes to repeat it, so we
> may
> > have the chance to look at it? Thanks.
> >
> > Regards,
> > Kai
> >
> > From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> > coheigea@apache.org>]
> > Sent: Monday, April 20, 2015 10:40 PM
> > To: Apache Directory Developers List
> > Subject: Kerby GSS tests?
> >
> > Hi all,
> >
> > Are there any tests in the source (or has anyone successfully tested) a
> > Java GSS client -> Apache Kerby?
> > The first issue I ran into was that neither the KdcNetwork nor the
> > NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> > fix it)?
> > I could work around the above by setting "udp_preference_limit = 1".
> > However, I then run into an issue where it fails due to no
> > pre-authentication data in the request. Are we sure that this parsing is
> > working correctly?
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks Colm for the great work!
Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
By the way, Yaning made the UDP support happen for the NettyKdcNetwork today,
https://issues.apache.org/jira/browse/DIRKRB-231
Regards,
Kai
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 29, 2015 6:38 PM
To: kerby@directory.apache.org
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok done!
Repository: directory-kerby
Updated Branches:
refs/heads/master e452f1854 -> eb2e4c1ae
Adding a GSS unit test
Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
Commit:
http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
Tree: http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
Diff: http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
Colm.
On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Colm,
>
> Yes it’s a known issue due to incomplete implementation. When the
> following one is resolved, I thought we could get back to this
> verifying the function. I will hopefully work on it recently.
> https://issues.apache.org/jira/browse/DIRKRB-235
>
> By the way, is it doable to port your end to end tests into Kerby,
> without introducing the many deps? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, April 27, 2015 6:46 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Thanks, everything is working now :-) The remaining issue is that the
> tests are failing when pre-auth is enabled. Do you want me to start
> looking into this, or are there known issues here?
> Colm.
>
> On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> It’s done now. The root cause is due to the incorrect TGS principal
> construction. Please check out latest codes and also apply the
> following change to your test project.
>
> Regards,
> Kai
>
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/authentication/AuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/authentication/AuthenticationTest.java
> @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> org.junit.Assert {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in
> Kerby)
>
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> H_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
> @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> org.junit.Assert {
> }
>
> @org.junit.Test
> - @org.junit.Ignore
> + //@org.junit.Ignore<ma...@org.junit.Ignore>
> public void unitTest() throws Exception {
> KrbClient client = new KrbClient();
>
> diff --git
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/jaxrs/JAXRSAuthenticationTest.java
> b/apache/cxf/cxf-k
> index 3806a70..802baa0 100644
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/jaxrs/JAXRSAuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/jaxrs/JAXRSAuthenticationTest.java
> @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> org.junit.Assert {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in
> Kerby)
>
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> H_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Friday, April 24, 2015 8:12 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> So it’s another issue existing in client side, right? I checked our
> today’s changes and found nothing related to the issue. It may be not
> caused by the fix of previous issue.
>
> I can’t debug on your project due to maven module deps. I saw no much
> difference from your test case with Kerby’s, but wonder why it’s ok in
> Kerby project.
> Will continue to investigate it tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, April 24, 2015 5:52 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Excellent thanks! However, now the unit test using the Kerby client
> API fails :-) The problem is in getting the TGT. Using the GSS client
> API, the value for the "PrincipalName principal =
> request.getReqBody().getSname();" in
> KdcRequest.checkServer() is:
>
> krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> However, using the Kerby client API it's:
>
> krbtgt
> and hence an error is thrown, as this principal is not stored. Any
> ideas here? You can reproduce just by updating my github project, and
> removing the @Ignore annotation from the "unitTest".
> Colm.
>
> On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It’s done! Below is my test running your test project. Please check
> latest codes and verify it, thanks!
>
> >>>DEBUG: TCPClient reading 594 bytes
> >>> KrbKdcReq send: #bytes read=594
> >>> KdcAccessibility: remove localhost:9002
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> http://service.ws.apache.org>
> Using builtin default etypes for default_tkt_enctypes default etypes
> for default_tkt_enctypes: 18 17 16 23 1 3.
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> Using builtin default etypes for permitted_enctypes default etypes for
> permitted_enctypes: 18 17 16 23 1 3.
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> replay cache for alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org> is null.
> object 0: 1429862199082/82299
> >>> KrbApReq: authenticate succeed.
> Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
>
> Results :
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
>
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] BUILD SUCCESS
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Total time: 6.770 s
> [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> 13M/262M [INFO]
> ----------------------------------------------------------------------
> --
> [drankye@zkdesk cxf-kerberos-kerby]$
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:31 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> There's no rush with any of this! I am just playing around with Kerby.
> Colm.
>
> On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, similar issue but this time is TransitedEncoding now. We need to
> go thru the codes to make sure service ticket is correctly filled. I
> will look at it tomorrow, kinds of tired now. Thanks for your patience!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:01 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok that looks good, the client is now working again, and I'm getting
> past the decoding of the client name. Now there is another error on
> the service side :-)
>
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> at
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> Colm.
>
> On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> This should fix the problem, but need some clean up. Will commit it
> after your confirmation.
>
> Regards,
> Kai
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:50 PM
>
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
> Subject: RE: Kerby GSS tests?
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> EncryptionType encryptionType = getEncryptionType();
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> + PrincipalName ticketPrincipal =
> + request.getReqBody().getSname();
>
> EncTicketPart encTicketPart = new EncTicketPart();
> KdcConfig config = kdcContext.getConfig();
> (END)
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:17
> 9)
> Colm.
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
> Regards,
> Kai
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:10 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:09 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> However, on the second time it is blank. This sounds like a similar
> bug that you fixed for when the cname was not in the request?
> Colm.
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> >> So now my client is successfully communicating with Kerby!
> It’s exciting! Thanks a lot.
>
> >>I'm getting an error in GSS when parsing the principal name
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what
> cname is set into the field?
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 6:43 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok I've figured out what the problem was. I was creating two
> principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> http://service.ws.apache.org>". The default value for the
> TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>" key
> was used first, and the other key was used for TGS. I solved it by
> just specifying "krbtgt/
> service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
> So now my client is successfully communicating with Kerby! However,
> I'm now running into a problem on the service side. I'm getting an
> error in GSS when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> Any ideas?
> Colm.
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It may be caused by bad backend? What’s backend you used? I thought
> two keys should be the same anyway.
>
> From: Zheng, Kai
> Sent: Thursday, April 23, 2015 5:52 PM
> To: 'coheigea@apache.org<ma...@apache.org>'
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
> Would you debug more? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 5:38 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> The two keys are not the same. They have the same encoding length +
> kvno + tagno, but different byte[] content.
> Colm.
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> It looks strange to me.
> Would you debug and check the two keys are the same in that place and
> the other place in KDC side KdcRequest:400:
> EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> serverKey, KeyUsage.KDC_REP_TICKET);
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Wednesday, April 22, 2015 11:15 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I get the same error (decryption error) with this patch.
> Colm.
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> Ticket ticket = apReq.getTicket();
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> }
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 10:46 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to
> get the encryption type right. It’s a certain one this time.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 10:01 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler.
> This is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> decrypted field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthent
> icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> right key to decrpyt the request?
> Colm.
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> Would you check out the fix below and verify it? Thanks!
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> Author: Drankye <dr...@gmail.com>>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
> Fixed the issue that cname field in KdcReqBody should not be used
> in TgsReq
>
> Regards,
> Kai
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 8:36 PM
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
>
> Subject: RE: Kerby GSS tests?
>
> I just checked the codes in MIT Kerberos. It was clear we should use
> the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> field in KdcReq is only used in AsReq, not used in TgsReq.
> I will have a fix for this shortly.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Wednesday, April 22, 2015 7:37 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal
> name in the TGT ticket, would you inspect the fields of the passed TGT
> and use the client field in it, when it’s null in the KdcReq? I will
> check and make sure which way we should go later. Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 6:17 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok with the current code I've made some progress - I can now
> successfully get a TGT from Kerby. However, I'm running into a
> puzzling issue when trying to get a service key. Essentially, the
> clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
> On the first TGT pass, the client + server principals in checkClient
> look
> like:
>
> Client PRINC: alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_SRV_INST
> On the second call:
>
> Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_UNKNOWN
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something
> odd with the parsing in Kerby.
> Colm.
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> I thought it’s good to have the following fix for now, as it processes
> the enctypes list from client from first to end. I just fired a
> follow-on issue to double check this.
> https://issues.apache.org/jira/browse/DIRKRB-236
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 8:53 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
> Is there any existing code in Apache Directory along these lines?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <kayyagari@apache.org
> <ma...@apache.org>> wrote:
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> Yes it’s a great fix! May be we could also update our related kdc test
> to repeat the issue and guard the fix? In our existing tests, the
> enctypes used in KrbClient are the same with the ones in KdcServer
> side, so we don’t find the issue until now. Yes, client may very
> likely request different enctypes that the KdcServer doesn’t support/enable yet.
>
> yes, clients can send different enctypes depending the platform they
> are running on.
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side and then pick the best from the
> ones requested by the client.
> Thanks again.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:33 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I've found another bug. We are just picking the first desired
> encryption type in KdcRequest.checkClient(). However, we may not
> actually have this key. This leads to an NPE. Example:
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException { Colm.
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
>
> Yep I will do!
> Colm.
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:11 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> Colm.
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
> Any ideas? The Kerby server + CXF client are both on the same machine...
> Colm.
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 6:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> http://127.0.0.1:9002>]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> Colm.
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
> Any ideas?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Monday, April 20, 2015 10:40 PM
> To: Apache Directory Developers List
> Subject: Kerby GSS tests?
>
> Hi all,
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks Colm for the great work!
Shall we resolve https://issues.apache.org/jira/browse/DIRKRB-232 now?
By the way, Yaning made the UDP support happen for the NettyKdcNetwork today,
https://issues.apache.org/jira/browse/DIRKRB-231
Regards,
Kai
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 29, 2015 6:38 PM
To: kerby@directory.apache.org
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok done!
Repository: directory-kerby
Updated Branches:
refs/heads/master e452f1854 -> eb2e4c1ae
Adding a GSS unit test
Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
Commit:
http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
Tree: http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
Diff: http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
Colm.
On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Colm,
>
> Yes it’s a known issue due to incomplete implementation. When the
> following one is resolved, I thought we could get back to this
> verifying the function. I will hopefully work on it recently.
> https://issues.apache.org/jira/browse/DIRKRB-235
>
> By the way, is it doable to port your end to end tests into Kerby,
> without introducing the many deps? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, April 27, 2015 6:46 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Thanks, everything is working now :-) The remaining issue is that the
> tests are failing when pre-auth is enabled. Do you want me to start
> looking into this, or are there known issues here?
> Colm.
>
> On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> It’s done now. The root cause is due to the incorrect TGS principal
> construction. Please check out latest codes and also apply the
> following change to your test project.
>
> Regards,
> Kai
>
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/authentication/AuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/authentication/AuthenticationTest.java
> @@ -98,9 +98,7 @@ public class AuthenticationTest extends
> org.junit.Assert {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in
> Kerby)
>
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> H_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
> @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> org.junit.Assert {
> }
>
> @org.junit.Test
> - @org.junit.Ignore
> + //@org.junit.Ignore<ma...@org.junit.Ignore>
> public void unitTest() throws Exception {
> KrbClient client = new KrbClient();
>
> diff --git
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/jaxrs/JAXRSAuthenticationTest.java
> b/apache/cxf/cxf-k
> index 3806a70..802baa0 100644
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/jaxrs/JAXRSAuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/
> kerberos/jaxrs/JAXRSAuthenticationTest.java
> @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> org.junit.Assert {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in
> Kerby)
>
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUT
> H_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Friday, April 24, 2015 8:12 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> So it’s another issue existing in client side, right? I checked our
> today’s changes and found nothing related to the issue. It may be not
> caused by the fix of previous issue.
>
> I can’t debug on your project due to maven module deps. I saw no much
> difference from your test case with Kerby’s, but wonder why it’s ok in
> Kerby project.
> Will continue to investigate it tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, April 24, 2015 5:52 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Excellent thanks! However, now the unit test using the Kerby client
> API fails :-) The problem is in getting the TGT. Using the GSS client
> API, the value for the "PrincipalName principal =
> request.getReqBody().getSname();" in
> KdcRequest.checkServer() is:
>
> krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> However, using the Kerby client API it's:
>
> krbtgt
> and hence an error is thrown, as this principal is not stored. Any
> ideas here? You can reproduce just by updating my github project, and
> removing the @Ignore annotation from the "unitTest".
> Colm.
>
> On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It’s done! Below is my test running your test project. Please check
> latest codes and verify it, thanks!
>
> >>>DEBUG: TCPClient reading 594 bytes
> >>> KrbKdcReq send: #bytes read=594
> >>> KdcAccessibility: remove localhost:9002
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> http://service.ws.apache.org>
> Using builtin default etypes for default_tkt_enctypes default etypes
> for default_tkt_enctypes: 18 17 16 23 1 3.
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> Using builtin default etypes for permitted_enctypes default etypes for
> permitted_enctypes: 18 17 16 23 1 3.
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> replay cache for alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org> is null.
> object 0: 1429862199082/82299
> >>> KrbApReq: authenticate succeed.
> Krb5Context setting peerSeqNumber to: 979244960 Krb5Context setting
> mySeqNumber to: 979244960 … … Apr 24, 2015 3:56:39 PM
> io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED Tests run:
> 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
>
> Results :
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
>
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] BUILD SUCCESS
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Total time: 6.770 s
> [INFO] Finished at: 2015-04-24T15:56:40+08:00 [INFO] Final Memory:
> 13M/262M [INFO]
> ----------------------------------------------------------------------
> --
> [drankye@zkdesk cxf-kerberos-kerby]$
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:31 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> There's no rush with any of this! I am just playing around with Kerby.
> Colm.
>
> On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, similar issue but this time is TransitedEncoding now. We need to
> go thru the codes to make sure service ticket is correctly filled. I
> will look at it tomorrow, kinds of tired now. Thanks for your patience!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:01 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok that looks good, the client is now working again, and I'm getting
> past the decoding of the client name. Now there is another error on
> the service side :-)
>
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> at
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> Colm.
>
> On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> This should fix the problem, but need some clean up. Will commit it
> after your confirmation.
>
> Regards,
> Kai
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:50 PM
>
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
> Subject: RE: Kerby GSS tests?
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> EncryptionType encryptionType = getEncryptionType();
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> + PrincipalName ticketPrincipal =
> + request.getReqBody().getSname();
>
> EncTicketPart encTicketPart = new EncTicketPart();
> KdcConfig config = kdcContext.getConfig();
> (END)
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:17
> 9)
> Colm.
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
> Regards,
> Kai
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:10 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:09 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> However, on the second time it is blank. This sounds like a similar
> bug that you fixed for when the cname was not in the request?
> Colm.
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> >> So now my client is successfully communicating with Kerby!
> It’s exciting! Thanks a lot.
>
> >>I'm getting an error in GSS when parsing the principal name
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what
> cname is set into the field?
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 6:43 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok I've figured out what the problem was. I was creating two
> principals called "krbtgt" and "krbtgt/service.ws.apache.org<
> http://service.ws.apache.org>". The default value for the
> TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So
> the "krbtgt/ service.ws.apache.org<http://service.ws.apache.org>" key
> was used first, and the other key was used for TGS. I solved it by
> just specifying "krbtgt/
> service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
> So now my client is successfully communicating with Kerby! However,
> I'm now running into a problem on the service side. I'm getting an
> error in GSS when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> Any ideas?
> Colm.
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It may be caused by bad backend? What’s backend you used? I thought
> two keys should be the same anyway.
>
> From: Zheng, Kai
> Sent: Thursday, April 23, 2015 5:52 PM
> To: 'coheigea@apache.org<ma...@apache.org>'
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
> Would you debug more? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 5:38 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> The two keys are not the same. They have the same encoding length +
> kvno + tagno, but different byte[] content.
> Colm.
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> It looks strange to me.
> Would you debug and check the two keys are the same in that place and
> the other place in KDC side KdcRequest:400:
> EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> serverKey, KeyUsage.KDC_REP_TICKET);
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Wednesday, April 22, 2015 11:15 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I get the same error (decryption error) with this patch.
> Colm.
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> Ticket ticket = apReq.getTicket();
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> }
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 10:46 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to
> get the encryption type right. It’s a certain one this time.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 10:01 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler.
> This is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server/request/TgsRequest.java @@ -73,9 +73,14 @@ public class
> TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on
> decrypted field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthent
> icator(TgsRequest.java:89) Are we sure that the tgsKey above is the
> right key to decrpyt the request?
> Colm.
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> Would you check out the fix below and verify it? Thanks!
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> Author: Drankye <dr...@gmail.com>>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
> Fixed the issue that cname field in KdcReqBody should not be used
> in TgsReq
>
> Regards,
> Kai
>
> From: Zheng, Kai
> [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 8:36 PM
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
>
> Subject: RE: Kerby GSS tests?
>
> I just checked the codes in MIT Kerberos. It was clear we should use
> the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname
> field in KdcReq is only used in AsReq, not used in TgsReq.
> I will have a fix for this shortly.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Wednesday, April 22, 2015 7:37 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal
> name in the TGT ticket, would you inspect the fields of the passed TGT
> and use the client field in it, when it’s null in the KdcReq? I will
> check and make sure which way we should go later. Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 6:17 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok with the current code I've made some progress - I can now
> successfully get a TGT from Kerby. However, I'm running into a
> puzzling issue when trying to get a service key. Essentially, the
> clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
> On the first TGT pass, the client + server principals in checkClient
> look
> like:
>
> Client PRINC: alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_SRV_INST
> On the second call:
>
> Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_UNKNOWN
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something
> odd with the parsing in Kerby.
> Colm.
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> I thought it’s good to have the following fix for now, as it processes
> the enctypes list from client from first to end. I just fired a
> follow-on issue to double check this.
> https://issues.apache.org/jira/browse/DIRKRB-236
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 8:53 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
> Is there any existing code in Apache Directory along these lines?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <kayyagari@apache.org
> <ma...@apache.org>> wrote:
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> Yes it’s a great fix! May be we could also update our related kdc test
> to repeat the issue and guard the fix? In our existing tests, the
> enctypes used in KrbClient are the same with the ones in KdcServer
> side, so we don’t find the issue until now. Yes, client may very
> likely request different enctypes that the KdcServer doesn’t support/enable yet.
>
> yes, clients can send different enctypes depending the platform they
> are running on.
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side and then pick the best from the
> ones requested by the client.
> Thanks again.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:33 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I've found another bug. We are just picking the first desired
> encryption type in KdcRequest.checkClient(). However, we may not
> actually have this key. This leads to an NPE. Example:
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/
> server @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException { Colm.
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
>
> Yep I will do!
> Colm.
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:11 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> Colm.
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
> Any ideas? The Kerby server + CXF client are both on the same machine...
> Colm.
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 6:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> http://127.0.0.1:9002>]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> Colm.
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
> Any ideas?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Monday, April 20, 2015 10:40 PM
> To: Apache Directory Developers List
> Subject: Kerby GSS tests?
>
> Hi all,
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok done!
Repository: directory-kerby
Updated Branches:
refs/heads/master e452f1854 -> eb2e4c1ae
Adding a GSS unit test
Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
Commit:
http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
Tree: http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
Diff: http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
Colm.
On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Colm,
>
> Yes it’s a known issue due to incomplete implementation. When the
> following one is resolved, I thought we could get back to this verifying
> the function. I will hopefully work on it recently.
> https://issues.apache.org/jira/browse/DIRKRB-235
>
> By the way, is it doable to port your end to end tests into Kerby, without
> introducing the many deps? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, April 27, 2015 6:46 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Thanks, everything is working now :-) The remaining issue is that the
> tests are failing when pre-auth is enabled. Do you want me to start looking
> into this, or are there known issues here?
> Colm.
>
> On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> It’s done now. The root cause is due to the incorrect TGS principal
> construction. Please check out latest codes and also apply the following
> change to your test project.
>
> Regards,
> Kai
>
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
> @@ -98,9 +98,7 @@ public class AuthenticationTest extends org.junit.Assert
> {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
> @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> org.junit.Assert {
> }
>
> @org.junit.Test
> - @org.junit.Ignore
> + //@org.junit.Ignore<ma...@org.junit.Ignore>
> public void unitTest() throws Exception {
> KrbClient client = new KrbClient();
>
> diff --git
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
> b/apache/cxf/cxf-k
> index 3806a70..802baa0 100644
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
> @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> org.junit.Assert {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Friday, April 24, 2015 8:12 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> So it’s another issue existing in client side, right? I checked our
> today’s changes and found nothing related to the issue. It may be not
> caused by the fix of previous issue.
>
> I can’t debug on your project due to maven module deps. I saw no much
> difference from your test case with Kerby’s, but wonder why it’s ok in
> Kerby project.
> Will continue to investigate it tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, April 24, 2015 5:52 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Excellent thanks! However, now the unit test using the Kerby client API
> fails :-)
> The problem is in getting the TGT. Using the GSS client API, the value for
> the "PrincipalName principal = request.getReqBody().getSname();" in
> KdcRequest.checkServer() is:
>
> krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> However, using the Kerby client API it's:
>
> krbtgt
> and hence an error is thrown, as this principal is not stored. Any ideas
> here? You can reproduce just by updating my github project, and removing
> the @Ignore annotation from the "unitTest".
> Colm.
>
> On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It’s done! Below is my test running your test project. Please check latest
> codes and verify it, thanks!
>
> >>>DEBUG: TCPClient reading 594 bytes
> >>> KrbKdcReq send: #bytes read=594
> >>> KdcAccessibility: remove localhost:9002
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> http://service.ws.apache.org>
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> Using builtin default etypes for permitted_enctypes
> default etypes for permitted_enctypes: 18 17 16 23 1 3.
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> replay cache for alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org> is null.
> object 0: 1429862199082/82299
> >>> KrbApReq: authenticate succeed.
> Krb5Context setting peerSeqNumber to: 979244960
> Krb5Context setting mySeqNumber to: 979244960
> …
> …
> Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
>
> Results :
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 6.770 s
> [INFO] Finished at: 2015-04-24T15:56:40+08:00
> [INFO] Final Memory: 13M/262M
> [INFO]
> ------------------------------------------------------------------------
> [drankye@zkdesk cxf-kerberos-kerby]$
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:31 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> There's no rush with any of this! I am just playing around with Kerby.
> Colm.
>
> On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, similar issue but this time is TransitedEncoding now. We need to go
> thru the codes to make sure service ticket is correctly filled. I will look
> at it tomorrow, kinds of tired now. Thanks for your patience!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:01 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok that looks good, the client is now working again, and I'm getting past
> the decoding of the client name. Now there is another error on the service
> side :-)
>
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> at
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> Colm.
>
> On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> This should fix the problem, but need some clean up. Will commit it after
> your confirmation.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:50 PM
>
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
> Subject: RE: Kerby GSS tests?
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> EncryptionType encryptionType = getEncryptionType();
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> + PrincipalName ticketPrincipal = request.getReqBody().getSname();
>
> EncTicketPart encTicketPart = new EncTicketPart();
> KdcConfig config = kdcContext.getConfig();
> (END)
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
> Colm.
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:10 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:09 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> However, on the second time it is blank. This sounds like a similar bug
> that you fixed for when the cname was not in the request?
> Colm.
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> >> So now my client is successfully communicating with Kerby!
> It’s exciting! Thanks a lot.
>
> >>I'm getting an error in GSS when parsing the principal name
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 6:43 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org<
> http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL
> is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/
> service.ws.apache.org<http://service.ws.apache.org>" key was used first,
> and the other key was used for TGS. I solved it by just specifying "krbtgt/
> service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL
> in KdcConfig.
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> Any ideas?
> Colm.
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
> From: Zheng, Kai
> Sent: Thursday, April 23, 2015 5:52 PM
> To: 'coheigea@apache.org<ma...@apache.org>'
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
> Would you debug more? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 5:38 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
> Colm.
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> It looks strange to me.
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
> EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> serverKey, KeyUsage.KDC_REP_TICKET);
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Wednesday, April 22, 2015 11:15 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I get the same error (decryption error) with this patch.
> Colm.
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> Ticket ticket = apReq.getTicket();
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> }
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 10:46 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 10:01 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
> Are we sure that the tgsKey above is the right key to decrpyt the request?
> Colm.
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> Would you check out the fix below and verify it? Thanks!
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> Author: Drankye <dr...@gmail.com>>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 8:36 PM
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
>
> Subject: RE: Kerby GSS tests?
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
> I will have a fix for this shortly.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Wednesday, April 22, 2015 7:37 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 6:17 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_SRV_INST
> On the second call:
>
> Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_UNKNOWN
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
> Colm.
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
> https://issues.apache.org/jira/browse/DIRKRB-236
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 8:53 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
> Is there any existing code in Apache Directory along these lines?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <kayyagari@apache.org
> <ma...@apache.org>> wrote:
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
> and then pick the best from the ones requested by the client.
> Thanks again.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:33 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
> Colm.
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
>
> Yep I will do!
> Colm.
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:11 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> Colm.
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
> Any ideas? The Kerby server + CXF client are both on the same machine...
> Colm.
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 6:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> http://127.0.0.1:9002>]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> Colm.
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
> Any ideas?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Monday, April 20, 2015 10:40 PM
> To: Apache Directory Developers List
> Subject: Kerby GSS tests?
>
> Hi all,
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok done!
Repository: directory-kerby
Updated Branches:
refs/heads/master e452f1854 -> eb2e4c1ae
Adding a GSS unit test
Project: http://git-wip-us.apache.org/repos/asf/directory-kerby/repo
Commit:
http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/eb2e4c1a
Tree: http://git-wip-us.apache.org/repos/asf/directory-kerby/tree/eb2e4c1a
Diff: http://git-wip-us.apache.org/repos/asf/directory-kerby/diff/eb2e4c1a
Colm.
On Mon, Apr 27, 2015 at 1:45 PM, Zheng, Kai <ka...@intel.com> wrote:
> Colm,
>
> Yes it’s a known issue due to incomplete implementation. When the
> following one is resolved, I thought we could get back to this verifying
> the function. I will hopefully work on it recently.
> https://issues.apache.org/jira/browse/DIRKRB-235
>
> By the way, is it doable to port your end to end tests into Kerby, without
> introducing the many deps? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Monday, April 27, 2015 6:46 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Thanks, everything is working now :-) The remaining issue is that the
> tests are failing when pre-auth is enabled. Do you want me to start looking
> into this, or are there known issues here?
> Colm.
>
> On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> It’s done now. The root cause is due to the incorrect TGS principal
> construction. Please check out latest codes and also apply the following
> change to your test project.
>
> Regards,
> Kai
>
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
> @@ -98,9 +98,7 @@ public class AuthenticationTest extends org.junit.Assert
> {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
> @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> org.junit.Assert {
> }
>
> @org.junit.Test
> - @org.junit.Ignore
> + //@org.junit.Ignore<ma...@org.junit.Ignore>
> public void unitTest() throws Exception {
> KrbClient client = new KrbClient();
>
> diff --git
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
> b/apache/cxf/cxf-k
> index 3806a70..802baa0 100644
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
> @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> org.junit.Assert {
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED,
> false);
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>");
> -
> +
> // Create principals
> String alice = "alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>";
> String bob = "bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>";
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Friday, April 24, 2015 8:12 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> So it’s another issue existing in client side, right? I checked our
> today’s changes and found nothing related to the issue. It may be not
> caused by the fix of previous issue.
>
> I can’t debug on your project due to maven module deps. I saw no much
> difference from your test case with Kerby’s, but wonder why it’s ok in
> Kerby project.
> Will continue to investigate it tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, April 24, 2015 5:52 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Excellent thanks! However, now the unit test using the Kerby client API
> fails :-)
> The problem is in getting the TGT. Using the GSS client API, the value for
> the "PrincipalName principal = request.getReqBody().getSname();" in
> KdcRequest.checkServer() is:
>
> krbtgt/service.ws.apache.org<http://service.ws.apache.org>
> However, using the Kerby client API it's:
>
> krbtgt
> and hence an error is thrown, as this principal is not stored. Any ideas
> here? You can reproduce just by updating my github project, and removing
> the @Ignore annotation from the "unitTest".
> Colm.
>
> On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It’s done! Below is my test running your test project. Please check latest
> codes and verify it, thanks!
>
> >>>DEBUG: TCPClient reading 594 bytes
> >>> KrbKdcReq send: #bytes read=594
> >>> KdcAccessibility: remove localhost:9002
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<
> http://service.ws.apache.org>
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> Using builtin default etypes for permitted_enctypes
> default etypes for permitted_enctypes: 18 17 16 23 1 3.
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> replay cache for alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org> is null.
> object 0: 1429862199082/82299
> >>> KrbApReq: authenticate succeed.
> Krb5Context setting peerSeqNumber to: 979244960
> Krb5Context setting mySeqNumber to: 979244960
> …
> …
> Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
>
> Results :
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 6.770 s
> [INFO] Finished at: 2015-04-24T15:56:40+08:00
> [INFO] Final Memory: 13M/262M
> [INFO]
> ------------------------------------------------------------------------
> [drankye@zkdesk cxf-kerberos-kerby]$
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:31 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> There's no rush with any of this! I am just playing around with Kerby.
> Colm.
>
> On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, similar issue but this time is TransitedEncoding now. We need to go
> thru the codes to make sure service ticket is correctly filled. I will look
> at it tomorrow, kinds of tired now. Thanks for your patience!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 9:01 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok that looks good, the client is now working again, and I'm getting past
> the decoding of the client name. Now there is another error on the service
> side :-)
>
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> at
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
> Colm.
>
> On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> This should fix the problem, but need some clean up. Will commit it after
> your confirmation.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:50 PM
>
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
> Subject: RE: Kerby GSS tests?
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
> EncryptionType encryptionType = getEncryptionType();
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
> + PrincipalName ticketPrincipal = request.getReqBody().getSname();
>
> EncTicketPart encTicketPart = new EncTicketPart();
> KdcConfig config = kdcContext.getConfig();
> (END)
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
> Colm.
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Thursday, April 23, 2015 7:10 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 7:09 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org<ma...@service.ws.apache.org>".
> However, on the second time it is blank. This sounds like a similar bug
> that you fixed for when the cname was not in the request?
> Colm.
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> >> So now my client is successfully communicating with Kerby!
> It’s exciting! Thanks a lot.
>
> >>I'm getting an error in GSS when parsing the principal name
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, April 23, 2015 6:43 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org<
> http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL
> is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/
> service.ws.apache.org<http://service.ws.apache.org>" key was used first,
> and the other key was used for TGS. I solved it by just specifying "krbtgt/
> service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL
> in KdcConfig.
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <ma...@service.ws.apache.org>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> Any ideas?
> Colm.
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
> From: Zheng, Kai
> Sent: Thursday, April 23, 2015 5:52 PM
> To: 'coheigea@apache.org<ma...@apache.org>'
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
> Would you debug more? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Thursday, April 23, 2015 5:38 PM
>
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
> Colm.
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> It looks strange to me.
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
> EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
> serverKey, KeyUsage.KDC_REP_TICKET);
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Wednesday, April 22, 2015 11:15 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I get the same error (decryption error) with this patch.
> Colm.
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> Ticket ticket = apReq.getTicket();
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
> }
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 10:46 PM
>
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 10:01 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
> Are we sure that the tgsKey above is the right key to decrpyt the request?
> Colm.
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Colm,
>
> Would you check out the fix below and verify it? Thanks!
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
> Author: Drankye <dr...@gmail.com>>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
> Sent: Wednesday, April 22, 2015 8:36 PM
> To: Apache Directory Developers List; coheigea@apache.org<mailto:
> coheigea@apache.org>
>
> Subject: RE: Kerby GSS tests?
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
> I will have a fix for this shortly.
>
> Regards,
> Kai
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Wednesday, April 22, 2015 7:37 PM
> To: coheigea@apache.org<ma...@apache.org>
> Cc: Apache Directory Developers List
> Subject: RE: Kerby GSS tests?
>
> Hi Colm,
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Wednesday, April 22, 2015 6:17 PM
> To: Zheng, Kai
> Cc: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org<mailto:
> alice@service.ws.apache.org>
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_SRV_INST
> On the second call:
>
> Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<mailto:
> service.ws.apache.org@service.ws.apache.org>
> Server PRINC type: NT_UNKNOWN
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
> Colm.
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
> https://issues.apache.org/jira/browse/DIRKRB-236
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 8:53 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
> Is there any existing code in Apache Directory along these lines?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <kayyagari@apache.org
> <ma...@apache.org>> wrote:
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
> and then pick the best from the ones requested by the client.
> Thanks again.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:33 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Hi Kai,
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
> Colm.
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
>
> Yep I will do!
> Colm.
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 7:11 PM
>
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
> Colm.
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
> Any ideas? The Kerby server + CXF client are both on the same machine...
> Colm.
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Tuesday, April 21, 2015 6:34 PM
> To: Apache Directory Developers List
> Subject: Re: Kerby GSS tests?
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<
> http://127.0.0.1:9002>]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> Colm.
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <coheigea@apache.org
> <ma...@apache.org>> wrote:
> Hi Kai,
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
> Any ideas?
> Colm.
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <kai.zheng@intel.com<mailto:
> kai.zheng@intel.com>> wrote:
> Hi Colm,
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
> Regards,
> Kai
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Monday, April 20, 2015 10:40 PM
> To: Apache Directory Developers List
> Subject: Kerby GSS tests?
>
> Hi all,
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Colm,
Yes it’s a known issue due to incomplete implementation. When the following one is resolved, I thought we could get back to this verifying the function. I will hopefully work on it recently.
https://issues.apache.org/jira/browse/DIRKRB-235
By the way, is it doable to port your end to end tests into Kerby, without introducing the many deps? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Monday, April 27, 2015 6:46 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Thanks, everything is working now :-) The remaining issue is that the tests are failing when pre-auth is enabled. Do you want me to start looking into this, or are there known issues here?
Colm.
On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
It’s done now. The root cause is due to the incorrect TGS principal construction. Please check out latest codes and also apply the following change to your test project.
Regards,
Kai
--- a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
+++ b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
@@ -98,9 +98,7 @@ public class AuthenticationTest extends org.junit.Assert {
// Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED, false);
- kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
- "krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>");
-
+
// Create principals
String alice = "alice@service.ws.apache.org<ma...@service.ws.apache.org>";
String bob = "bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>";
@@ -136,7 +134,7 @@ public class AuthenticationTest extends org.junit.Assert {
}
@org.junit.Test
- @org.junit.Ignore
+ //@org.junit.Ignore<ma...@org.junit.Ignore>
public void unitTest() throws Exception {
KrbClient client = new KrbClient();
diff --git a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java b/apache/cxf/cxf-k
index 3806a70..802baa0 100644
--- a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
+++ b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
@@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends org.junit.Assert {
// Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED, false);
- kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
- "krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>");
-
+
// Create principals
String alice = "alice@service.ws.apache.org<ma...@service.ws.apache.org>";
String bob = "bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>";
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Friday, April 24, 2015 8:12 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
So it’s another issue existing in client side, right? I checked our today’s changes and found nothing related to the issue. It may be not caused by the fix of previous issue.
I can’t debug on your project due to maven module deps. I saw no much difference from your test case with Kerby’s, but wonder why it’s ok in Kerby project.
Will continue to investigate it tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 5:52 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Excellent thanks! However, now the unit test using the Kerby client API fails :-)
The problem is in getting the TGT. Using the GSS client API, the value for the "PrincipalName principal = request.getReqBody().getSname();" in KdcRequest.checkServer() is:
krbtgt/service.ws.apache.org<http://service.ws.apache.org>
However, using the Kerby client API it's:
krbtgt
and hence an error is thrown, as this principal is not stored. Any ideas here? You can reproduce just by updating my github project, and removing the @Ignore annotation from the "unitTest".
Colm.
On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <ka...@intel.com>> wrote:
It’s done! Below is my test running your test project. Please check latest codes and verify it, thanks!
>>>DEBUG: TCPClient reading 594 bytes
>>> KrbKdcReq send: #bytes read=594
>>> KdcAccessibility: remove localhost:9002
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<http://service.ws.apache.org>
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23 1 3.
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
replay cache for alice@service.ws.apache.org<ma...@service.ws.apache.org> is null.
object 0: 1429862199082/82299
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 979244960
Krb5Context setting mySeqNumber to: 979244960
…
…
Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.770 s
[INFO] Finished at: 2015-04-24T15:56:40+08:00
[INFO] Final Memory: 13M/262M
[INFO] ------------------------------------------------------------------------
[drankye@zkdesk cxf-kerberos-kerby]$
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:31 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
There's no rush with any of this! I am just playing around with Kerby.
Colm.
On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, similar issue but this time is TransitedEncoding now. We need to go thru the codes to make sure service ticket is correctly filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok that looks good, the client is now working again, and I'm getting past the decoding of the client name. Now there is another error on the service side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com>> wrote:
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Colm,
Yes it’s a known issue due to incomplete implementation. When the following one is resolved, I thought we could get back to this verifying the function. I will hopefully work on it recently.
https://issues.apache.org/jira/browse/DIRKRB-235
By the way, is it doable to port your end to end tests into Kerby, without introducing the many deps? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Monday, April 27, 2015 6:46 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Thanks, everything is working now :-) The remaining issue is that the tests are failing when pre-auth is enabled. Do you want me to start looking into this, or are there known issues here?
Colm.
On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
It’s done now. The root cause is due to the incorrect TGS principal construction. Please check out latest codes and also apply the following change to your test project.
Regards,
Kai
--- a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
+++ b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
@@ -98,9 +98,7 @@ public class AuthenticationTest extends org.junit.Assert {
// Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED, false);
- kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
- "krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>");
-
+
// Create principals
String alice = "alice@service.ws.apache.org<ma...@service.ws.apache.org>";
String bob = "bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>";
@@ -136,7 +134,7 @@ public class AuthenticationTest extends org.junit.Assert {
}
@org.junit.Test
- @org.junit.Ignore
+ //@org.junit.Ignore<ma...@org.junit.Ignore>
public void unitTest() throws Exception {
KrbClient client = new KrbClient();
diff --git a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java b/apache/cxf/cxf-k
index 3806a70..802baa0 100644
--- a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
+++ b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
@@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends org.junit.Assert {
// Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED, false);
- kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
- "krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>");
-
+
// Create principals
String alice = "alice@service.ws.apache.org<ma...@service.ws.apache.org>";
String bob = "bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>";
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Friday, April 24, 2015 8:12 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
So it’s another issue existing in client side, right? I checked our today’s changes and found nothing related to the issue. It may be not caused by the fix of previous issue.
I can’t debug on your project due to maven module deps. I saw no much difference from your test case with Kerby’s, but wonder why it’s ok in Kerby project.
Will continue to investigate it tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 5:52 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Excellent thanks! However, now the unit test using the Kerby client API fails :-)
The problem is in getting the TGT. Using the GSS client API, the value for the "PrincipalName principal = request.getReqBody().getSname();" in KdcRequest.checkServer() is:
krbtgt/service.ws.apache.org<http://service.ws.apache.org>
However, using the Kerby client API it's:
krbtgt
and hence an error is thrown, as this principal is not stored. Any ideas here? You can reproduce just by updating my github project, and removing the @Ignore annotation from the "unitTest".
Colm.
On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <ka...@intel.com>> wrote:
It’s done! Below is my test running your test project. Please check latest codes and verify it, thanks!
>>>DEBUG: TCPClient reading 594 bytes
>>> KrbKdcReq send: #bytes read=594
>>> KdcAccessibility: remove localhost:9002
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<http://service.ws.apache.org>
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23 1 3.
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
replay cache for alice@service.ws.apache.org<ma...@service.ws.apache.org> is null.
object 0: 1429862199082/82299
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 979244960
Krb5Context setting mySeqNumber to: 979244960
…
…
Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.770 s
[INFO] Finished at: 2015-04-24T15:56:40+08:00
[INFO] Final Memory: 13M/262M
[INFO] ------------------------------------------------------------------------
[drankye@zkdesk cxf-kerberos-kerby]$
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:31 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
There's no rush with any of this! I am just playing around with Kerby.
Colm.
On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, similar issue but this time is TransitedEncoding now. We need to go thru the codes to make sure service ticket is correctly filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok that looks good, the client is now working again, and I'm getting past the decoding of the client name. Now there is another error on the service side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com>> wrote:
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Thanks, everything is working now :-) The remaining issue is that the tests
are failing when pre-auth is enabled. Do you want me to start looking into
this, or are there known issues here?
Colm.
On Sat, Apr 25, 2015 at 12:39 AM, Zheng, Kai <ka...@intel.com> wrote:
> Colm,
>
>
>
> It’s done now. The root cause is due to the incorrect TGS principal
> construction. Please check out latest codes and also apply the following
> change to your test project.
>
>
>
> Regards,
>
> Kai
>
>
>
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
>
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
>
> @@ -98,9 +98,7 @@ public class AuthenticationTest extends org.junit.Assert
> {
>
>
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
>
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED,
> false);
>
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
>
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org");
>
> -
>
> +
>
> // Create principals
>
> String alice = "alice@service.ws.apache.org";
>
> String bob = "bob/service.ws.apache.org@service.ws.apache.org";
>
> @@ -136,7 +134,7 @@ public class AuthenticationTest extends
> org.junit.Assert {
>
> }
>
>
>
> @org.junit.Test
>
> - @org.junit.Ignore
>
> + //@org.junit.Ignore
>
> public void unitTest() throws Exception {
>
> KrbClient client = new KrbClient();
>
>
>
> diff --git
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
> b/apache/cxf/cxf-k
>
> index 3806a70..802baa0 100644
>
> ---
> a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
>
> +++
> b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
>
> @@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends
> org.junit.Assert {
>
>
>
> // Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
>
>
> kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED,
> false);
>
> -
> kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
>
> - "krbtgt/
> service.ws.apache.org@service.ws.apache.org");
>
> -
>
> +
>
> // Create principals
>
> String alice = "alice@service.ws.apache.org";
>
> String bob = "bob/service.ws.apache.org@service.ws.apache.org";
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Friday, April 24, 2015 8:12 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> So it’s another issue existing in client side, right? I checked our
> today’s changes and found nothing related to the issue. It may be not
> caused by the fix of previous issue.
>
>
>
> I can’t debug on your project due to maven module deps. I saw no much
> difference from your test case with Kerby’s, but wonder why it’s ok in
> Kerby project.
>
> Will continue to investigate it tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Friday, April 24, 2015 5:52 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Excellent thanks! However, now the unit test using the Kerby client API
> fails :-)
>
> The problem is in getting the TGT. Using the GSS client API, the value for
> the "PrincipalName principal = request.getReqBody().getSname();" in
> KdcRequest.checkServer() is:
>
> krbtgt/service.ws.apache.org
>
> However, using the Kerby client API it's:
>
> krbtgt
>
> and hence an error is thrown, as this principal is not stored. Any ideas
> here? You can reproduce just by updating my github project, and removing
> the @Ignore annotation from the "unitTest".
>
> Colm.
>
>
>
> On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> It’s done! Below is my test running your test project. Please check latest
> codes and verify it, thanks!
>
>
>
> >>>DEBUG: TCPClient reading 594 bytes
>
> >>> KrbKdcReq send: #bytes read=594
>
> >>> KdcAccessibility: remove localhost:9002
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>
> >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org
>
> Using builtin default etypes for default_tkt_enctypes
>
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>
> Using builtin default etypes for permitted_enctypes
>
> default etypes for permitted_enctypes: 18 17 16 23 1 3.
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>
> replay cache for alice@service.ws.apache.org is null.
>
> object 0: 1429862199082/82299
>
> >>> KrbApReq: authenticate succeed.
>
> Krb5Context setting peerSeqNumber to: 979244960
>
> Krb5Context setting mySeqNumber to: 979244960
>
> …
>
> …
>
> Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
>
> INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
>
>
>
> Results :
>
>
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
>
>
>
> [INFO]
> ------------------------------------------------------------------------
>
> [INFO] BUILD SUCCESS
>
> [INFO]
> ------------------------------------------------------------------------
>
> [INFO] Total time: 6.770 s
>
> [INFO] Finished at: 2015-04-24T15:56:40+08:00
>
> [INFO] Final Memory: 13M/262M
>
> [INFO]
> ------------------------------------------------------------------------
>
> [drankye@zkdesk cxf-kerberos-kerby]$
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 9:31 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> There's no rush with any of this! I am just playing around with Kerby.
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, similar issue but this time is TransitedEncoding now. We need to go
> thru the codes to make sure service ticket is correctly filled. I will look
> at it tomorrow, kinds of tired now. Thanks for your patience!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 9:01 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok that looks good, the client is now working again, and I'm getting past
> the decoding of the client name. Now there is another error on the service
> side :-)
>
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> at
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> This should fix the problem, but need some clean up. Will commit it after
> your confirmation.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:50 PM
>
>
> *To:* Apache Directory Developers List; coheigea@apache.org
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
>
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
>
> EncryptionType encryptionType = getEncryptionType();
>
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
>
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
>
> + PrincipalName ticketPrincipal = request.getReqBody().getSname();
>
>
>
> EncTicketPart encTicketPart = new EncTicketPart();
>
> KdcConfig config = kdcContext.getConfig();
>
> (END)
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:10 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:09 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org". However, on the second time it is blank.
> This sounds like a similar bug that you fixed for when the cname was not in
> the request?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> >> So now my client is successfully communicating with Kerby!
>
> It’s exciting! Thanks a lot.
>
>
>
> >>I'm getting an error in GSS when parsing the principal name
>
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 6:43 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org". The default value for
> the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM". So the "krbtgt/
> service.ws.apache.org" key was used first, and the other key was used for
> TGS. I solved it by just specifying "krbtgt/service.ws.apache.org" as the
> TGS_PRINCIPAL in KdcConfig.
>
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
>
> Any ideas?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
>
>
> *From:* Zheng, Kai
> *Sent:* Thursday, April 23, 2015 5:52 PM
> *To:* 'coheigea@apache.org'
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
>
> Would you debug more? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 5:38 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Colm,
It’s done now. The root cause is due to the incorrect TGS principal construction. Please check out latest codes and also apply the following change to your test project.
Regards,
Kai
--- a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
+++ b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/authentication/AuthenticationTest.java
@@ -98,9 +98,7 @@ public class AuthenticationTest extends org.junit.Assert {
// Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED, false);
- kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
- "krbtgt/service.ws.apache.org@service.ws.apache.org");
-
+
// Create principals
String alice = "alice@service.ws.apache.org";
String bob = "bob/service.ws.apache.org@service.ws.apache.org";
@@ -136,7 +134,7 @@ public class AuthenticationTest extends org.junit.Assert {
}
@org.junit.Test
- @org.junit.Ignore
+ //@org.junit.Ignore
public void unitTest() throws Exception {
KrbClient client = new KrbClient();
diff --git a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java b/apache/cxf/cxf-k
index 3806a70..802baa0 100644
--- a/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
+++ b/apache/cxf/cxf-kerberos-kerby/src/test/java/org/apache/coheigea/cxf/kerberos/jaxrs/JAXRSAuthenticationTest.java
@@ -87,9 +87,7 @@ public class JAXRSAuthenticationTest extends org.junit.Assert {
// Need to disable PRE_AUTH (not sure why, maybe a bug in Kerby)
kerbyServer.getSetting().getKdcConfig().setBoolean(KdcConfigKey.PREAUTH_REQUIRED, false);
- kerbyServer.getSetting().getKdcConfig().setString(KdcConfigKey.TGS_PRINCIPAL,
- "krbtgt/service.ws.apache.org@service.ws.apache.org");
-
+
// Create principals
String alice = "alice@service.ws.apache.org";
String bob = "bob/service.ws.apache.org@service.ws.apache.org";
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Friday, April 24, 2015 8:12 PM
To: coheigea@apache.org
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
So it’s another issue existing in client side, right? I checked our today’s changes and found nothing related to the issue. It may be not caused by the fix of previous issue.
I can’t debug on your project due to maven module deps. I saw no much difference from your test case with Kerby’s, but wonder why it’s ok in Kerby project.
Will continue to investigate it tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 5:52 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Excellent thanks! However, now the unit test using the Kerby client API fails :-)
The problem is in getting the TGT. Using the GSS client API, the value for the "PrincipalName principal = request.getReqBody().getSname();" in KdcRequest.checkServer() is:
krbtgt/service.ws.apache.org<http://service.ws.apache.org>
However, using the Kerby client API it's:
krbtgt
and hence an error is thrown, as this principal is not stored. Any ideas here? You can reproduce just by updating my github project, and removing the @Ignore annotation from the "unitTest".
Colm.
On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <ka...@intel.com>> wrote:
It’s done! Below is my test running your test project. Please check latest codes and verify it, thanks!
>>>DEBUG: TCPClient reading 594 bytes
>>> KrbKdcReq send: #bytes read=594
>>> KdcAccessibility: remove localhost:9002
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<http://service.ws.apache.org>
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23 1 3.
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
replay cache for alice@service.ws.apache.org<ma...@service.ws.apache.org> is null.
object 0: 1429862199082/82299
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 979244960
Krb5Context setting mySeqNumber to: 979244960
…
…
Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.770 s
[INFO] Finished at: 2015-04-24T15:56:40+08:00
[INFO] Final Memory: 13M/262M
[INFO] ------------------------------------------------------------------------
[drankye@zkdesk cxf-kerberos-kerby]$
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:31 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
There's no rush with any of this! I am just playing around with Kerby.
Colm.
On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, similar issue but this time is TransitedEncoding now. We need to go thru the codes to make sure service ticket is correctly filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok that looks good, the client is now working again, and I'm getting past the decoding of the client name. Now there is another error on the service side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com>> wrote:
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
So it’s another issue existing in client side, right? I checked our today’s changes and found nothing related to the issue. It may be not caused by the fix of previous issue.
I can’t debug on your project due to maven module deps. I saw no much difference from your test case with Kerby’s, but wonder why it’s ok in Kerby project.
Will continue to investigate it tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 5:52 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Excellent thanks! However, now the unit test using the Kerby client API fails :-)
The problem is in getting the TGT. Using the GSS client API, the value for the "PrincipalName principal = request.getReqBody().getSname();" in KdcRequest.checkServer() is:
krbtgt/service.ws.apache.org<http://service.ws.apache.org>
However, using the Kerby client API it's:
krbtgt
and hence an error is thrown, as this principal is not stored. Any ideas here? You can reproduce just by updating my github project, and removing the @Ignore annotation from the "unitTest".
Colm.
On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <ka...@intel.com>> wrote:
It’s done! Below is my test running your test project. Please check latest codes and verify it, thanks!
>>>DEBUG: TCPClient reading 594 bytes
>>> KrbKdcReq send: #bytes read=594
>>> KdcAccessibility: remove localhost:9002
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<http://service.ws.apache.org>
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23 1 3.
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
replay cache for alice@service.ws.apache.org<ma...@service.ws.apache.org> is null.
object 0: 1429862199082/82299
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 979244960
Krb5Context setting mySeqNumber to: 979244960
…
…
Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.770 s
[INFO] Finished at: 2015-04-24T15:56:40+08:00
[INFO] Final Memory: 13M/262M
[INFO] ------------------------------------------------------------------------
[drankye@zkdesk cxf-kerberos-kerby]$
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:31 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
There's no rush with any of this! I am just playing around with Kerby.
Colm.
On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, similar issue but this time is TransitedEncoding now. We need to go thru the codes to make sure service ticket is correctly filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok that looks good, the client is now working again, and I'm getting past the decoding of the client name. Now there is another error on the service side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com>> wrote:
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Oh, ok, I’ll look at it shortly.
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 5:52 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Excellent thanks! However, now the unit test using the Kerby client API fails :-)
The problem is in getting the TGT. Using the GSS client API, the value for the "PrincipalName principal = request.getReqBody().getSname();" in KdcRequest.checkServer() is:
krbtgt/service.ws.apache.org<http://service.ws.apache.org>
However, using the Kerby client API it's:
krbtgt
and hence an error is thrown, as this principal is not stored. Any ideas here? You can reproduce just by updating my github project, and removing the @Ignore annotation from the "unitTest".
Colm.
On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <ka...@intel.com>> wrote:
It’s done! Below is my test running your test project. Please check latest codes and verify it, thanks!
>>>DEBUG: TCPClient reading 594 bytes
>>> KrbKdcReq send: #bytes read=594
>>> KdcAccessibility: remove localhost:9002
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org<http://service.ws.apache.org>
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23 1 3.
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
replay cache for alice@service.ws.apache.org<ma...@service.ws.apache.org> is null.
object 0: 1429862199082/82299
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 979244960
Krb5Context setting mySeqNumber to: 979244960
…
…
Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.770 s
[INFO] Finished at: 2015-04-24T15:56:40+08:00
[INFO] Final Memory: 13M/262M
[INFO] ------------------------------------------------------------------------
[drankye@zkdesk cxf-kerberos-kerby]$
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:31 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
There's no rush with any of this! I am just playing around with Kerby.
Colm.
On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, similar issue but this time is TransitedEncoding now. We need to go thru the codes to make sure service ticket is correctly filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok that looks good, the client is now working again, and I'm getting past the decoding of the client name. Now there is another error on the service side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com>> wrote:
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Excellent thanks! However, now the unit test using the Kerby client API
fails :-)
The problem is in getting the TGT. Using the GSS client API, the value for
the "PrincipalName principal = request.getReqBody().getSname();" in
KdcRequest.checkServer() is:
krbtgt/service.ws.apache.org
However, using the Kerby client API it's:
krbtgt
and hence an error is thrown, as this principal is not stored. Any ideas
here? You can reproduce just by updating my github project, and removing
the @Ignore annotation from the "unitTest".
Colm.
On Fri, Apr 24, 2015 at 1:02 AM, Zheng, Kai <ka...@intel.com> wrote:
> It’s done! Below is my test running your test project. Please check
> latest codes and verify it, thanks!
>
>
>
> >>>DEBUG: TCPClient reading 594 bytes
>
> >>> KrbKdcReq send: #bytes read=594
>
> >>> KdcAccessibility: remove localhost:9002
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>
> >>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org
>
> Using builtin default etypes for default_tkt_enctypes
>
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
>
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>
> Using builtin default etypes for permitted_enctypes
>
> default etypes for permitted_enctypes: 18 17 16 23 1 3.
>
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>
> replay cache for alice@service.ws.apache.org is null.
>
> object 0: 1429862199082/82299
>
> >>> KrbApReq: authenticate succeed.
>
> Krb5Context setting peerSeqNumber to: 979244960
>
> Krb5Context setting mySeqNumber to: 979244960
>
> …
>
> …
>
> Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
>
> INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
>
>
>
> Results :
>
>
>
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
>
>
>
> [INFO]
> ------------------------------------------------------------------------
>
> [INFO] BUILD SUCCESS
>
> [INFO]
> ------------------------------------------------------------------------
>
> [INFO] Total time: 6.770 s
>
> [INFO] Finished at: 2015-04-24T15:56:40+08:00
>
> [INFO] Final Memory: 13M/262M
>
> [INFO]
> ------------------------------------------------------------------------
>
> [drankye@zkdesk cxf-kerberos-kerby]$
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 9:31 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> There's no rush with any of this! I am just playing around with Kerby.
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, similar issue but this time is TransitedEncoding now. We need to go
> thru the codes to make sure service ticket is correctly filled. I will look
> at it tomorrow, kinds of tired now. Thanks for your patience!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 9:01 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok that looks good, the client is now working again, and I'm getting past
> the decoding of the client name. Now there is another error on the service
> side :-)
>
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> at
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> This should fix the problem, but need some clean up. Will commit it after
> your confirmation.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:50 PM
>
>
> *To:* Apache Directory Developers List; coheigea@apache.org
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
>
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
>
> EncryptionType encryptionType = getEncryptionType();
>
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
>
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
>
> + PrincipalName ticketPrincipal = request.getReqBody().getSname();
>
>
>
> EncTicketPart encTicketPart = new EncTicketPart();
>
> KdcConfig config = kdcContext.getConfig();
>
> (END)
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:10 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:09 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org". However, on the second time it is blank.
> This sounds like a similar bug that you fixed for when the cname was not in
> the request?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> >> So now my client is successfully communicating with Kerby!
>
> It’s exciting! Thanks a lot.
>
>
>
> >>I'm getting an error in GSS when parsing the principal name
>
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 6:43 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org". The default value for
> the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM". So the "krbtgt/
> service.ws.apache.org" key was used first, and the other key was used for
> TGS. I solved it by just specifying "krbtgt/service.ws.apache.org" as the
> TGS_PRINCIPAL in KdcConfig.
>
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
>
> Any ideas?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
>
>
> *From:* Zheng, Kai
> *Sent:* Thursday, April 23, 2015 5:52 PM
> *To:* 'coheigea@apache.org'
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
>
> Would you debug more? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 5:38 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
It’s done! Below is my test running your test project. Please check latest codes and verify it, thanks!
>>>DEBUG: TCPClient reading 594 bytes
>>> KrbKdcReq send: #bytes read=594
>>> KdcAccessibility: remove localhost:9002
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply bob/service.ws.apache.org
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 16 23 1 3.
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
replay cache for alice@service.ws.apache.org is null.
object 0: 1429862199082/82299
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 979244960
Krb5Context setting mySeqNumber to: 979244960
…
…
Apr 24, 2015 3:56:39 PM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0x856913ae, /0:0:0:0:0:0:0:0:9002] UNREGISTERED
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.233 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.770 s
[INFO] Finished at: 2015-04-24T15:56:40+08:00
[INFO] Final Memory: 13M/262M
[INFO] ------------------------------------------------------------------------
[drankye@zkdesk cxf-kerberos-kerby]$
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 9:31 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
There's no rush with any of this! I am just playing around with Kerby.
Colm.
On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, similar issue but this time is TransitedEncoding now. We need to go thru the codes to make sure service ticket is correctly filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 9:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok that looks good, the client is now working again, and I'm getting past the decoding of the client name. Now there is another error on the service side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com>> wrote:
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
There's no rush with any of this! I am just playing around with Kerby.
Colm.
On Thu, Apr 23, 2015 at 2:28 PM, Zheng, Kai <ka...@intel.com> wrote:
> Yes, similar issue but this time is TransitedEncoding now. We need to go
> thru the codes to make sure service ticket is correctly filled. I will look
> at it tomorrow, kinds of tired now. Thanks for your patience!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 9:01 PM
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok that looks good, the client is now working again, and I'm getting past
> the decoding of the client name. Now there is another error on the service
> side :-)
>
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at
> sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
> at
> sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> This should fix the problem, but need some clean up. Will commit it after
> your confirmation.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:50 PM
>
>
> *To:* Apache Directory Developers List; coheigea@apache.org
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
>
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
>
> EncryptionType encryptionType = getEncryptionType();
>
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
>
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
>
> + PrincipalName ticketPrincipal = request.getReqBody().getSname();
>
>
>
> EncTicketPart encTicketPart = new EncTicketPart();
>
> KdcConfig config = kdcContext.getConfig();
>
> (END)
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:10 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:09 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org". However, on the second time it is blank.
> This sounds like a similar bug that you fixed for when the cname was not in
> the request?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> >> So now my client is successfully communicating with Kerby!
>
> It’s exciting! Thanks a lot.
>
>
>
> >>I'm getting an error in GSS when parsing the principal name
>
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 6:43 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org". The default value for
> the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM". So the "krbtgt/
> service.ws.apache.org" key was used first, and the other key was used for
> TGS. I solved it by just specifying "krbtgt/service.ws.apache.org" as the
> TGS_PRINCIPAL in KdcConfig.
>
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
>
> Any ideas?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
>
>
> *From:* Zheng, Kai
> *Sent:* Thursday, April 23, 2015 5:52 PM
> *To:* 'coheigea@apache.org'
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
>
> Would you debug more? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 5:38 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Yes, similar issue but this time is TransitedEncoding now. We need to go thru the codes to make sure service ticket is correctly filled. I will look at it tomorrow, kinds of tired now. Thanks for your patience!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 9:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok that looks good, the client is now working again, and I'm getting past the decoding of the client name. Now there is another error on the service side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com>> wrote:
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok that looks good, the client is now working again, and I'm getting past
the decoding of the client name. Now there is another error on the service
side :-)
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at
sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at
sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at
sun.security.krb5.internal.TransitedEncoding.<init>(TransitedEncoding.java:76)
at
sun.security.krb5.internal.TransitedEncoding.parse(TransitedEncoding.java:133)
at
sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:156)
at
sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:144)
Colm.
On Thu, Apr 23, 2015 at 1:03 PM, Zheng, Kai <ka...@intel.com> wrote:
> This should fix the problem, but need some clean up. Will commit it
> after your confirmation.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:50 PM
>
> *To:* Apache Directory Developers List; coheigea@apache.org
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Would you have a try with this? I will double check what’s the correct
> way. Thanks.
>
>
>
> @@ -281,7 +281,7 @@ public abstract class KdcRequest {
>
> EncryptionType encryptionType = getEncryptionType();
>
> EncryptionKey serverKey =
> getServerEntry().getKeys().get(encryptionType
>
>
>
> - PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
>
> + PrincipalName ticketPrincipal = request.getReqBody().getSname();
>
>
>
> EncTicketPart encTicketPart = new EncTicketPart();
>
> KdcConfig config = kdcContext.getConfig();
>
> (END)
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> It appears there is a regression in the fix, I'm now getting a client
> error:
>
> KrbException: Message stream modified (41)
> at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:10 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:09 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org". However, on the second time it is blank.
> This sounds like a similar bug that you fixed for when the cname was not in
> the request?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> >> So now my client is successfully communicating with Kerby!
>
> It’s exciting! Thanks a lot.
>
>
>
> >>I'm getting an error in GSS when parsing the principal name
>
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 6:43 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org". The default value for
> the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM". So the "krbtgt/
> service.ws.apache.org" key was used first, and the other key was used for
> TGS. I solved it by just specifying "krbtgt/service.ws.apache.org" as the
> TGS_PRINCIPAL in KdcConfig.
>
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
>
> Any ideas?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
>
>
> *From:* Zheng, Kai
> *Sent:* Thursday, April 23, 2015 5:52 PM
> *To:* 'coheigea@apache.org'
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
>
> Would you debug more? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 5:38 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
This should fix the problem, but need some clean up. Will commit it after your confirmation.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, April 23, 2015 7:50 PM
To: Apache Directory Developers List; coheigea@apache.org
Subject: RE: Kerby GSS tests?
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Would you have a try with this? I will double check what’s the correct way. Thanks.
@@ -281,7 +281,7 @@ public abstract class KdcRequest {
EncryptionType encryptionType = getEncryptionType();
EncryptionKey serverKey = getServerEntry().getKeys().get(encryptionType
- PrincipalName ticketPrincipal = getIssueTicketServerPrincipal();
+ PrincipalName ticketPrincipal = request.getReqBody().getSname();
EncTicketPart encTicketPart = new EncTicketPart();
KdcConfig config = kdcContext.getConfig();
(END)
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
It appears there is a regression in the fix, I'm now getting a client error:
KrbException: Message stream modified (41)
at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:56)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:88)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at
sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:309)
at
sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at
sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454)
at
sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
Colm.
On Thu, Apr 23, 2015 at 12:25 PM, Zheng, Kai <ka...@intel.com> wrote:
> Colm would you check the latest fix? Just committed, though I’m not
> perfectly sure. It may has some other issues, but will check some time
> later, when having tests in hand.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Thursday, April 23, 2015 7:10 PM
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Yes you’re right. I’m working on a fix. Will let you know soon.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 7:09 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The first time we hit "issueTicket" the CName is correct "
> alice@service.ws.apache.org". However, on the second time it is blank.
> This sounds like a similar bug that you fixed for when the cname was not in
> the request?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> >> So now my client is successfully communicating with Kerby!
>
> It’s exciting! Thanks a lot.
>
>
>
> >>I'm getting an error in GSS when parsing the principal name
>
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 6:43 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org". The default value for
> the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM". So the "krbtgt/
> service.ws.apache.org" key was used first, and the other key was used for
> TGS. I solved it by just specifying "krbtgt/service.ws.apache.org" as the
> TGS_PRINCIPAL in KdcConfig.
>
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
>
> Any ideas?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
>
>
> *From:* Zheng, Kai
> *Sent:* Thursday, April 23, 2015 5:52 PM
> *To:* 'coheigea@apache.org'
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
>
> Would you debug more? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 5:38 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Colm would you check the latest fix? Just committed, though I’m not perfectly sure. It may has some other issues, but will check some time later, when having tests in hand.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, April 23, 2015 7:10 PM
To: coheigea@apache.org
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Yes you’re right. I’m working on a fix. Will let you know soon.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 7:09 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The first time we hit "issueTicket" the CName is correct "alice@service.ws.apache.org<ma...@service.ws.apache.org>". However, on the second time it is blank. This sounds like a similar bug that you fixed for when the cname was not in the request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
The first time we hit "issueTicket" the CName is correct "
alice@service.ws.apache.org". However, on the second time it is blank. This
sounds like a similar bug that you fixed for when the cname was not in the
request?
Colm.
On Thu, Apr 23, 2015 at 11:54 AM, Zheng, Kai <ka...@intel.com> wrote:
> Hi Colm,
>
>
>
> >> So now my client is successfully communicating with Kerby!
>
> It’s exciting! Thanks a lot.
>
>
>
> >>I'm getting an error in GSS when parsing the principal name
>
> Looks like it failed to parse cname in encpart in the service ticket.
> Would you debug into the issueTicket() in KdcRequest and check what cname
> is set into the field?
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Thursday, April 23, 2015 6:43 PM
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok I've figured out what the problem was. I was creating two principals
> called "krbtgt" and "krbtgt/service.ws.apache.org". The default value for
> the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM". So the "krbtgt/
> service.ws.apache.org" key was used first, and the other key was used for
> TGS. I solved it by just specifying "krbtgt/service.ws.apache.org" as the
> TGS_PRINCIPAL in KdcConfig.
>
> So now my client is successfully communicating with Kerby! However, I'm
> now running into a problem on the service side. I'm getting an error in GSS
> when parsing the principal name:
>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> Entered Krb5Context.acceptSecContext with state=STATE_NEW
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
> at
> sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
> at sun.security.util.DerValue.<init>(DerValue.java:252)
> at
> sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
> at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
> at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
> at
> sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
> at
> sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
>
> Any ideas?
>
> Colm.
>
>
>
> On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
>
>
> *From:* Zheng, Kai
> *Sent:* Thursday, April 23, 2015 5:52 PM
> *To:* 'coheigea@apache.org'
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
>
> Would you debug more? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 5:38 PM
>
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
>> So now my client is successfully communicating with Kerby!
It’s exciting! Thanks a lot.
>>I'm getting an error in GSS when parsing the principal name
Looks like it failed to parse cname in encpart in the service ticket. Would you debug into the issueTicket() in KdcRequest and check what cname is set into the field?
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 6:43 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok I've figured out what the problem was. I was creating two principals called "krbtgt" and "krbtgt/service.ws.apache.org<http://service.ws.apache.org>". The default value for the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM<ma...@EXAMPLE.COM>". So the "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" key was used first, and the other key was used for TGS. I solved it by just specifying "krbtgt/service.ws.apache.org<http://service.ws.apache.org>" as the TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now running into a problem on the service side. I'm getting an error in GSS when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com>> wrote:
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org<ma...@apache.org>'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok I've figured out what the problem was. I was creating two principals
called "krbtgt" and "krbtgt/service.ws.apache.org". The default value for
the TGS_PRINCIPAL is "krbtgt@EXAMPLE.COM". So the "krbtgt/
service.ws.apache.org" key was used first, and the other key was used for
TGS. I solved it by just specifying "krbtgt/service.ws.apache.org" as the
TGS_PRINCIPAL in KdcConfig.
So now my client is successfully communicating with Kerby! However, I'm now
running into a problem on the service side. I'm getting an error in GSS
when parsing the principal name:
Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big.
at
sun.security.util.DerInputStream.getLength(DerInputStream.java:561)
at sun.security.util.DerValue.<init>(DerValue.java:252)
at
sun.security.util.DerInputStream.getDerValue(DerInputStream.java:417)
at sun.security.krb5.PrincipalName.<init>(PrincipalName.java:228)
at sun.security.krb5.PrincipalName.parse(PrincipalName.java:285)
at
sun.security.krb5.internal.EncTicketPart.init(EncTicketPart.java:155)
at
sun.security.krb5.internal.EncTicketPart.<init>(EncTicketPart.java:105)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
Any ideas?
Colm.
On Thu, Apr 23, 2015 at 10:53 AM, Zheng, Kai <ka...@intel.com> wrote:
> It may be caused by bad backend? What’s backend you used? I thought two
> keys should be the same anyway.
>
>
>
> *From:* Zheng, Kai
> *Sent:* Thursday, April 23, 2015 5:52 PM
> *To:* 'coheigea@apache.org'
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Oh bad, looks like the key use to issue ticket isn’t the same one to
> decrypt it in TgsRequest processing. The encryption type should be the
> same, right, but then why we two different key values or keys?
>
> Would you debug more? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Thursday, April 23, 2015 5:38 PM
>
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> The two keys are not the same. They have the same encoding length + kvno +
> tagno, but different byte[] content.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
It may be caused by bad backend? What’s backend you used? I thought two keys should be the same anyway.
From: Zheng, Kai
Sent: Thursday, April 23, 2015 5:52 PM
To: 'coheigea@apache.org'
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Oh bad, looks like the key use to issue ticket isn’t the same one to decrypt it in TgsRequest processing. The encryption type should be the same, right, but then why we two different key values or keys?
Would you debug more? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Thursday, April 23, 2015 5:38 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno + tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Kai,
The two keys are not the same. They have the same encoding length + kvno +
tagno, but different byte[] content.
Colm.
On Wed, Apr 22, 2015 at 5:05 PM, Zheng, Kai <ka...@intel.com> wrote:
> Hi Colm,
>
>
>
> It looks strange to me.
>
> Would you debug and check the two keys are the same in that place and the
> other place in KDC side KdcRequest:400:
>
> EncryptedData encryptedData = EncryptionUtil.*seal*(encTicketPart,
> serverKey, KeyUsage.*KDC_REP_TICKET*);
>
>
>
> Thanks. I’m going to sleep now. See you tomorrow.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Wednesday, April 22, 2015 11:15 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I get the same error (decryption error) with this patch.
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
It looks strange to me.
Would you debug and check the two keys are the same in that place and the other place in KDC side KdcRequest:400:
EncryptedData encryptedData = EncryptionUtil.seal(encTicketPart,
serverKey, KeyUsage.KDC_REP_TICKET);
Thanks. I’m going to sleep now. See you tomorrow.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 11:15 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Kai,
I get the same error (decryption error) with this patch.
Colm.
On Wed, Apr 22, 2015 at 3:57 PM, Zheng, Kai <ka...@intel.com> wrote:
> Hi Colm,
>
>
>
> The fix would be as follows. Would you verify and commit it if OK? Thanks.
>
>
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listItera
>
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> -
>
> Ticket ticket = apReq.getTicket();
>
> + EncryptionType encType = ticket.getEncryptedEncPart().getEType();
>
> + EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
>
> if (ticket.getTktvno() != KrbConstant.KRB_V5) {
>
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
>
> }
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 10:46 PM
>
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> >> Are we sure that the tgsKey above is the right key to decrpyt the
> request?
>
> Yes, the ticket there to decrypt is actually for TGS to interpret and
> validate, a tgs key should be used. I’m still thinking about how to get the
> encryption type right. It’s a certain one this time.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 10:01 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Looks good thanks! The next problem is an NPE in EncryptionHandler. This
> is caused by a similar issue to before:
>
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
> @@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
> throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
> }
>
> - EncryptionType encType =
> getKdcReq().getReqBody().getEtypes().listIterator().next();
> - EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
> -
> + EncryptionKey tgsKey = null;
> + for (EncryptionType encType :
> getKdcReq().getReqBody().getEtypes()) {
> + if (getTgsEntry().getKeys().containsKey(encType)) {
> + tgsKey = getTgsEntry().getKeys().get(encType);
> + break;
> + }
> + }
> +
>
> However, this patch results in the error:
>
> org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
> field failed
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
> at
> org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
> at
> org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
> at
> org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
> at
> org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
>
> Are we sure that the tgsKey above is the right key to decrpyt the request?
>
> Colm.
>
>
>
> On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
The fix would be as follows. Would you verify and commit it if OK? Thanks.
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listItera
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
Ticket ticket = apReq.getTicket();
+ EncryptionType encType = ticket.getEncryptedEncPart().getEType();
+ EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
if (ticket.getTktvno() != KrbConstant.KRB_V5) {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_BADVERSION);
}
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 10:46 PM
To: coheigea@apache.org
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
>> Are we sure that the tgsKey above is the right key to decrpyt the request?
Yes, the ticket there to decrypt is actually for TGS to interpret and validate, a tgs key should be used. I’m still thinking about how to get the encryption type right. It’s a certain one this time.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 10:01 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is caused by a similar issue to before:
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType = getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType : getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted field failed
at org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com<ma...@intel.com>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org<ma...@apache.org>
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Looks good thanks! The next problem is an NPE in EncryptionHandler. This is
caused by a similar issue to before:
---
a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
+++
b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TgsRequest.java
@@ -73,9 +73,14 @@ public class TgsRequest extends KdcRequest {
throw new KrbException(KrbErrorCode.KRB_AP_ERR_MSG_TYPE);
}
- EncryptionType encType =
getKdcReq().getReqBody().getEtypes().listIterator().next();
- EncryptionKey tgsKey = getTgsEntry().getKeys().get(encType);
-
+ EncryptionKey tgsKey = null;
+ for (EncryptionType encType :
getKdcReq().getReqBody().getEtypes()) {
+ if (getTgsEntry().getKeys().containsKey(encType)) {
+ tgsKey = getTgsEntry().getKeys().get(encType);
+ break;
+ }
+ }
+
However, this patch results in the error:
org.apache.kerby.kerberos.kerb.KrbException: Integrity check on decrypted
field failed
at
org.apache.kerby.kerberos.kerb.crypto.enc.KeKiEnc.decryptWith(KeKiEnc.java:116)
at
org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:160)
at
org.apache.kerby.kerberos.kerb.crypto.enc.AbstractEncTypeHandler.decrypt(AbstractEncTypeHandler.java:148)
at
org.apache.kerby.kerberos.kerb.crypto.EncryptionHandler.decrypt(EncryptionHandler.java:165)
at
org.apache.kerby.kerberos.kerb.common.EncryptionUtil.unseal(EncryptionUtil.java:132)
at
org.apache.kerby.kerberos.kerb.server.request.TgsRequest.verifyAuthenticator(TgsRequest.java:89)
Are we sure that the tgsKey above is the right key to decrpyt the request?
Colm.
On Wed, Apr 22, 2015 at 2:27 PM, Zheng, Kai <ka...@intel.com> wrote:
> Colm,
>
>
>
> Would you check out the fix below and verify it? Thanks!
>
>
>
> commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
>
> Author: Drankye <dr...@gmail.com>
>
> Date: Wed Apr 22 21:25:21 2015 +0800
>
>
>
> Fixed the issue that cname field in KdcReqBody should not be used in
> TgsReq
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com]
> *Sent:* Wednesday, April 22, 2015 8:36 PM
> *To:* Apache Directory Developers List; coheigea@apache.org
>
> *Subject:* RE: Kerby GSS tests?
>
>
>
> I just checked the codes in MIT Kerberos. It was clear we should use the
> value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in
> KdcReq is only used in AsReq, not used in TgsReq.
>
> I will have a fix for this shortly.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Zheng, Kai [mailto:kai.zheng@intel.com <ka...@intel.com>]
> *Sent:* Wednesday, April 22, 2015 7:37 PM
> *To:* coheigea@apache.org
> *Cc:* Apache Directory Developers List
> *Subject:* RE: Kerby GSS tests?
>
>
>
> Hi Colm,
>
>
>
> Thanks for your good progress and analysis. I’m not sure how KDC would
> handle in such case, but a possibility is to use the client principal name
> in the TGT ticket, would you inspect the fields of the passed TGT and use
> the client field in it, when it’s null in the KdcReq? I will check and make
> sure which way we should go later. Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org
> <co...@apache.org>]
> *Sent:* Wednesday, April 22, 2015 6:17 PM
> *To:* Zheng, Kai
> *Cc:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> Ok with the current code I've made some progress - I can now successfully
> get a TGT from Kerby. However, I'm running into a puzzling issue when
> trying to get a service key. Essentially, the clientPrincipal in
> KdcRequest.checkClient() is an empty String (and has a "null" NameType).
> This means that it just tries to retrieve the client Principal using
> @realm, and this fails.
>
> On the first TGT pass, the client + server principals in checkClient look
> like:
>
> Client PRINC: alice@service.ws.apache.org
> Client PRINC type: NT_PRINCIPAL
> Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_SRV_INST
>
> On the second call:
>
> Client PRINC: @service.ws.apache.org
> Client PRINC type: NT_UNKNOWN
> Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
> Server PRINC type: NT_UNKNOWN
>
> The SName looks find. But the CName is missing. I know this code works
> fine with the KDC in Apache Directory, so we must be doing something odd
> with the parsing in Kerby.
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <dr...@gmail.com>
Date: Wed Apr 22 21:25:21 2015 +0800
Fixed the issue that cname field in KdcReqBody should not be used in TgsReq
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List; coheigea@apache.org
Subject: RE: Kerby GSS tests?
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org<ma...@apache.org>
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
I just checked the codes in MIT Kerberos. It was clear we should use the value of TgsReq->pa->ApReq->ticket->encpart->cname. The cname field in KdcReq is only used in AsReq, not used in TgsReq.
I will have a fix for this shortly.
Regards,
Kai
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, April 22, 2015 7:37 PM
To: coheigea@apache.org
Cc: Apache Directory Developers List
Subject: RE: Kerby GSS tests?
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
Thanks for your good progress and analysis. I’m not sure how KDC would handle in such case, but a possibility is to use the client principal name in the TGT ticket, would you inspect the fields of the passed TGT and use the client field in it, when it’s null in the KdcReq? I will check and make sure which way we should go later. Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, April 22, 2015 6:17 PM
To: Zheng, Kai
Cc: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like:
Client PRINC: alice@service.ws.apache.org<ma...@service.ws.apache.org>
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org<http://service.ws.apache.org>
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org<ma...@service.ws.apache.org>
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok with the current code I've made some progress - I can now successfully
get a TGT from Kerby. However, I'm running into a puzzling issue when
trying to get a service key. Essentially, the clientPrincipal in
KdcRequest.checkClient() is an empty String (and has a "null" NameType).
This means that it just tries to retrieve the client Principal using
@realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look
like:
Client PRINC: alice@service.ws.apache.org
Client PRINC type: NT_PRINCIPAL
Server PRINC: krbtgt/service.ws.apache.org@service.ws.apache.org
Server PRINC type: NT_SRV_INST
On the second call:
Client PRINC: @service.ws.apache.org
Client PRINC type: NT_UNKNOWN
Server PRINC: bob/service.ws.apache.org@service.ws.apache.org
Server PRINC type: NT_UNKNOWN
The SName looks find. But the CName is missing. I know this code works fine
with the KDC in Apache Directory, so we must be doing something odd with
the parsing in Kerby.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok good idea, I've merged the fix.
Colm.
On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <ka...@intel.com> wrote:
> Hi Colm,
>
>
>
> I thought it’s good to have the following fix for now, as it processes the
> enctypes list from client from first to end. I just fired a follow-on issue
> to double check this.
>
> https://issues.apache.org/jira/browse/DIRKRB-236
>
>
>
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 8:53 PM
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kiran,
>
> > The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> Is there any existing code in Apache Directory along these lines?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>
>
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
>
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Kiran Ayyagari
> http://keydap.com
>
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
I thought it’s good to have the following fix for now, as it processes the enctypes list from client from first to end. I just fired a follow-on issue to double check this.
https://issues.apache.org/jira/browse/DIRKRB-236
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, April 21, 2015 8:53 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kiran,
> The enctypes should always be sorted from the most to least strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
yes, clients can send different enctypes depending the platform they are running on.
The enctypes should always be sorted from the most to least strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Kiran Ayyagari
http://keydap.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Kiran,
> The enctypes should always be sorted from the most to least
strong/preferred on the server side
Is there any existing code in Apache Directory along these lines?
Colm.
On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <ka...@apache.org>
wrote:
>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
>
>> Hi Colm,
>>
>>
>>
>> Yes it’s a great fix! May be we could also update our related kdc test to
>> repeat the issue and guard the fix? In our existing tests, the enctypes
>> used in KrbClient are the same with the ones in KdcServer side, so we don’t
>> find the issue until now. Yes, client may very likely request different
>> enctypes that the KdcServer doesn’t support/enable yet.
>>
>>
>>
> yes, clients can send different enctypes depending the platform they are
> running on.
>
> The enctypes should always be sorted from the most to least
> strong/preferred on the server side
> and then pick the best from the ones requested by the client.
>
> Thanks again.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Tuesday, April 21, 2015 7:33 PM
>>
>> *To:* Apache Directory Developers List
>> *Subject:* Re: Kerby GSS tests?
>>
>>
>>
>> Hi Kai,
>>
>> I've found another bug. We are just picking the first desired encryption
>> type in KdcRequest.checkClient(). However, we may not actually have this
>> key. This leads to an NPE. Example:
>>
>> We are requesting:
>>
>> aes256-cts-hmac-sha1-96 18
>> aes128-cts-hmac-sha1-96 17
>> des3-cbc-sha1 16
>> arcfour-hmac 23
>> des-cbc-crc 1
>> des-cbc-md5 3
>>
>> We pick the first one...however we only have the following keys stored:
>>
>> des3-cbc-sha1 16
>> aes128-cts-hmac-sha1-96 17
>>
>> What do you think of this patch?
>>
>> diff --git
>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
>> index 2165e17..e6bcef0 100644
>> ---
>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>> +++
>> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
>> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
>> setClientEntry(clientEntry);
>>
>> - EncryptionType encType =
>> request.getReqBody().getEtypes().listIterator(
>> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
>> - setClientKey(clientKey);
>> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
>> + if (clientEntry.getKeys().containsKey(encType)) {
>> + EncryptionKey clientKey =
>> clientEntry.getKeys().get(encType);
>> + setClientKey(clientKey);
>> + break;
>> + }
>> + }
>> }
>>
>> protected void preauth() throws KrbException {
>>
>> Colm.
>>
>>
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <
>> coheigea@apache.org> wrote:
>>
>>
>>
>> Yep I will do!
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>>
>> Yes, it looks like a good fix, 0 is there instead of null, for time
>> fields in kdc request. Would you double check other time values by the way?
>> Thanks!
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Tuesday, April 21, 2015 7:11 PM
>>
>>
>> *To:* Apache Directory Developers List
>> *Subject:* Re: Kerby GSS tests?
>>
>>
>>
>>
>>
>> The problem above is that the "end time" is 0 instead of "null". What do
>> you think of this patch?
>>
>> diff --git
>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
>> index 3d49af3..23275fc 100644
>> ---
>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>> +++
>> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
>> }
>>
>> KerberosTime krbEndTime = request.getReqBody().getTill();
>> - if (krbEndTime == null) {
>> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
>> krbEndTime =
>> krbStartTime.extend(config.getMaximumTicketLifetime()
>> } else if (krbStartTime.greaterThan(krbEndTime)) {
>> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
>> coheigea@apache.org> wrote:
>>
>> Hi Kai,
>>
>> 2. Please disable preauth in KDC side or require preauth in client
>> side. Looks like client didn’t send preauth data but KDC required it.
>>
>>
>>
>> Ok I got a bit further by doing this. However, from what I can find out,
>> the GSS client code should be sending the Pre authentication data (and
>> there appears to be no option to disable it). So I think there may be a bug
>> in how Kerby is processing the header? Should we log a JIRA to track this?
>>
>> The error I now get (when disabling pre auth in Kerby) is:
>>
>> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
>> later than end time
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
>> at
>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>> at
>> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>>
>> Any ideas? The Kerby server + CXF client are both on the same machine...
>>
>> Colm.
>>
>>
>>
>>
>>
>> If you don’t want to trouble with the config stuff, please just change
>> the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Tuesday, April 21, 2015 6:34 PM
>> *To:* Apache Directory Developers List
>> *Subject:* Re: Kerby GSS tests?
>>
>>
>>
>> Actually I spoke too soon, I do know how to reproduce the
>> "pre-authentication" error. Simply uncomment the line
>> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
>> put a printStackTrace in the NettyKdcServerImpl, I see:
>>
>> Error occured while processing request:Generic error (description in
>> e-text)
>> SocketTimeOutException with attempt: 2
>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
>> #bytes=169
>> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
>> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
>> 127.0.0.1:43973 => /127.0.0.1:9002]
>> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
>> (description in e-text)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
>> at
>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
>> coheigea@apache.org> wrote:
>>
>> Hi Kai,
>>
>> Thanks for your response. I have a test-case of sorts that shows the
>> interop failure (although I can't reproduce the issue I reported yesterday
>> about the preauthentication data).
>>
>>
>> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>>
>> Run it with "mvn clean install". You may need the install the parent
>> module as well before running this, which is one level up.
>>
>> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
>> client API to successfully communicate with it. Then I have a Apache
>> CXF-based test which uses the Kerberos functionality here (based on GSS) to
>> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
>> output looks like:
>>
>> Loaded from Java config
>> >>> KdcAccessibility: reset
>> >>> KdcAccessibility: reset
>> Using builtin default etypes for default_tkt_enctypes
>> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>> >>> KrbAsReq creating message
>> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
>> retries =3, #bytes=169
>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
>> #bytes=169
>> java.net.SocketTimeoutException: Read timed out
>> at java.net.SocketInputStream.socketRead0(Native Method)
>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> at java.net.SocketInputStream.read(SocketInputStream.java:210)
>> at java.io.DataInputStream.readInt(DataInputStream.java:387)
>> at
>> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
>> at
>> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:745)
>> >>>DEBUG: TCPClient could not read length field
>> >>> KrbKdcReq send: #bytes read=0
>>
>> Any ideas?
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>>
>> Hi Colm,
>>
>>
>>
>> We haven’t any test for GSS client against Kerby yet, though we do have
>> tests in protocol level for ApReq (in kerb-core-test module). We might look
>> at existing ApacheDS Kerberos codes to see if any such end to end tests to
>> port.
>>
>>
>>
>> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
>> to be done yet. I originally got them done some days ago, but recently I
>> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
>> would be good to record them.
>>
>>
>>
>> For the issue you ran into, do you have test codes to repeat it, so we
>> may have the chance to look at it? Thanks.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Monday, April 20, 2015 10:40 PM
>> *To:* Apache Directory Developers List
>> *Subject:* Kerby GSS tests?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Are there any tests in the source (or has anyone successfully tested) a
>> Java GSS client -> Apache Kerby?
>>
>> The first issue I ran into was that neither the KdcNetwork nor the
>> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
>> fix it)?
>>
>> I could work around the above by setting "udp_preference_limit = 1".
>> However, I then run into an issue where it fails due to no
>> pre-authentication data in the request. Are we sure that this parsing is
>> working correctly?
>>
>> Colm.
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <ka...@intel.com> wrote:
> Hi Colm,
>
>
>
> Yes it’s a great fix! May be we could also update our related kdc test to
> repeat the issue and guard the fix? In our existing tests, the enctypes
> used in KrbClient are the same with the ones in KdcServer side, so we don’t
> find the issue until now. Yes, client may very likely request different
> enctypes that the KdcServer doesn’t support/enable yet.
>
>
>
yes, clients can send different enctypes depending the platform they are
running on.
The enctypes should always be sorted from the most to least
strong/preferred on the server side
and then pick the best from the ones requested by the client.
Thanks again.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:33 PM
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Hi Kai,
>
> I've found another bug. We are just picking the first desired encryption
> type in KdcRequest.checkClient(). However, we may not actually have this
> key. This leads to an NPE. Example:
>
> We are requesting:
>
> aes256-cts-hmac-sha1-96 18
> aes128-cts-hmac-sha1-96 17
> des3-cbc-sha1 16
> arcfour-hmac 23
> des-cbc-crc 1
> des-cbc-md5 3
>
> We pick the first one...however we only have the following keys stored:
>
> des3-cbc-sha1 16
> aes128-cts-hmac-sha1-96 17
>
> What do you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 2165e17..e6bcef0 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -239,9 +239,13 @@ public abstract class KdcRequest {
> KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
> setClientEntry(clientEntry);
>
> - EncryptionType encType =
> request.getReqBody().getEtypes().listIterator(
> - EncryptionKey clientKey = clientEntry.getKeys().get(encType);
> - setClientKey(clientKey);
> + for (EncryptionType encType : request.getReqBody().getEtypes()) {
> + if (clientEntry.getKeys().containsKey(encType)) {
> + EncryptionKey clientKey =
> clientEntry.getKeys().get(encType);
> + setClientKey(clientKey);
> + break;
> + }
> + }
> }
>
> protected void preauth() throws KrbException {
>
> Colm.
>
>
>
>
>
> On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
>
>
> Yep I will do!
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
> Yes, it looks like a good fix, 0 is there instead of null, for time fields
> in kdc request. Would you double check other time values by the way? Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Kiran Ayyagari
http://keydap.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
Yes it’s a great fix! May be we could also update our related kdc test to repeat the issue and guard the fix? In our existing tests, the enctypes used in KrbClient are the same with the ones in KdcServer side, so we don’t find the issue until now. Yes, client may very likely request different enctypes that the KdcServer doesn’t support/enable yet.
Thanks again.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, April 21, 2015 7:33 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
I've found another bug. We are just picking the first desired encryption type in KdcRequest.checkClient(). However, we may not actually have this key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType = request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey = clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com>> wrote:
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Kai,
I've found another bug. We are just picking the first desired encryption
type in KdcRequest.checkClient(). However, we may not actually have this
key. This leads to an NPE. Example:
We are requesting:
aes256-cts-hmac-sha1-96 18
aes128-cts-hmac-sha1-96 17
des3-cbc-sha1 16
arcfour-hmac 23
des-cbc-crc 1
des-cbc-md5 3
We pick the first one...however we only have the following keys stored:
des3-cbc-sha1 16
aes128-cts-hmac-sha1-96 17
What do you think of this patch?
diff --git
a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 2165e17..e6bcef0 100644
---
a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++
b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -239,9 +239,13 @@ public abstract class KdcRequest {
KrbIdentity clientEntry = getEntry(clientPrincipal.getName());
setClientEntry(clientEntry);
- EncryptionType encType =
request.getReqBody().getEtypes().listIterator(
- EncryptionKey clientKey = clientEntry.getKeys().get(encType);
- setClientKey(clientKey);
+ for (EncryptionType encType : request.getReqBody().getEtypes()) {
+ if (clientEntry.getKeys().containsKey(encType)) {
+ EncryptionKey clientKey =
clientEntry.getKeys().get(encType);
+ setClientKey(clientKey);
+ break;
+ }
+ }
}
protected void preauth() throws KrbException {
Colm.
On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <co...@apache.org>
wrote:
>
> Yep I will do!
>
> Colm.
>
> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
>
>> Yes, it looks like a good fix, 0 is there instead of null, for time
>> fields in kdc request. Would you double check other time values by the way?
>> Thanks!
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Tuesday, April 21, 2015 7:11 PM
>>
>> *To:* Apache Directory Developers List
>> *Subject:* Re: Kerby GSS tests?
>>
>>
>>
>>
>>
>> The problem above is that the "end time" is 0 instead of "null". What do
>> you think of this patch?
>>
>> diff --git
>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
>> index 3d49af3..23275fc 100644
>> ---
>> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>> +++
>> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
>> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
>> }
>>
>> KerberosTime krbEndTime = request.getReqBody().getTill();
>> - if (krbEndTime == null) {
>> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
>> krbEndTime =
>> krbStartTime.extend(config.getMaximumTicketLifetime()
>> } else if (krbStartTime.greaterThan(krbEndTime)) {
>> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <
>> coheigea@apache.org> wrote:
>>
>> Hi Kai,
>>
>> 2. Please disable preauth in KDC side or require preauth in client
>> side. Looks like client didn’t send preauth data but KDC required it.
>>
>>
>>
>> Ok I got a bit further by doing this. However, from what I can find out,
>> the GSS client code should be sending the Pre authentication data (and
>> there appears to be no option to disable it). So I think there may be a bug
>> in how Kerby is processing the header? Should we log a JIRA to track this?
>>
>> The error I now get (when disabling pre auth in Kerby) is:
>>
>> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is
>> later than end time
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
>> at
>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>> at
>> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>>
>> Any ideas? The Kerby server + CXF client are both on the same machine...
>>
>> Colm.
>>
>>
>>
>>
>>
>> If you don’t want to trouble with the config stuff, please just change
>> the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Tuesday, April 21, 2015 6:34 PM
>> *To:* Apache Directory Developers List
>> *Subject:* Re: Kerby GSS tests?
>>
>>
>>
>> Actually I spoke too soon, I do know how to reproduce the
>> "pre-authentication" error. Simply uncomment the line
>> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
>> put a printStackTrace in the NettyKdcServerImpl, I see:
>>
>> Error occured while processing request:Generic error (description in
>> e-text)
>> SocketTimeOutException with attempt: 2
>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
>> #bytes=169
>> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
>> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
>> 127.0.0.1:43973 => /127.0.0.1:9002]
>> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
>> (description in e-text)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
>> at
>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
>> coheigea@apache.org> wrote:
>>
>> Hi Kai,
>>
>> Thanks for your response. I have a test-case of sorts that shows the
>> interop failure (although I can't reproduce the issue I reported yesterday
>> about the preauthentication data).
>>
>>
>> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>>
>> Run it with "mvn clean install". You may need the install the parent
>> module as well before running this, which is one level up.
>>
>> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
>> client API to successfully communicate with it. Then I have a Apache
>> CXF-based test which uses the Kerberos functionality here (based on GSS) to
>> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
>> output looks like:
>>
>> Loaded from Java config
>> >>> KdcAccessibility: reset
>> >>> KdcAccessibility: reset
>> Using builtin default etypes for default_tkt_enctypes
>> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>> >>> KrbAsReq creating message
>> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
>> retries =3, #bytes=169
>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
>> #bytes=169
>> java.net.SocketTimeoutException: Read timed out
>> at java.net.SocketInputStream.socketRead0(Native Method)
>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> at java.net.SocketInputStream.read(SocketInputStream.java:210)
>> at java.io.DataInputStream.readInt(DataInputStream.java:387)
>> at
>> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
>> at
>> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:745)
>> >>>DEBUG: TCPClient could not read length field
>> >>> KrbKdcReq send: #bytes read=0
>>
>> Any ideas?
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>>
>> Hi Colm,
>>
>>
>>
>> We haven’t any test for GSS client against Kerby yet, though we do have
>> tests in protocol level for ApReq (in kerb-core-test module). We might look
>> at existing ApacheDS Kerberos codes to see if any such end to end tests to
>> port.
>>
>>
>>
>> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
>> to be done yet. I originally got them done some days ago, but recently I
>> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
>> would be good to record them.
>>
>>
>>
>> For the issue you ran into, do you have test codes to repeat it, so we
>> may have the chance to look at it? Thanks.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Monday, April 20, 2015 10:40 PM
>> *To:* Apache Directory Developers List
>> *Subject:* Kerby GSS tests?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Are there any tests in the source (or has anyone successfully tested) a
>> Java GSS client -> Apache Kerby?
>>
>> The first issue I ran into was that neither the KdcNetwork nor the
>> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
>> fix it)?
>>
>> I could work around the above by setting "udp_preference_limit = 1".
>> However, I then run into an issue where it fails due to no
>> pre-authentication data in the request. Are we sure that this parsing is
>> working correctly?
>>
>> Colm.
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <ka...@intel.com> wrote:
> Yes, it looks like a good fix, 0 is there instead of null, for time
> fields in kdc request. Would you double check other time values by the way?
> Thanks!
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 7:11 PM
>
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
>
>
> The problem above is that the "end time" is 0 instead of "null". What do
> you think of this patch?
>
> diff --git
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
> index 3d49af3..23275fc 100644
> ---
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> +++
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
> @@ -370,7 +370,7 @@ public abstract class KdcRequest {
> }
>
> KerberosTime krbEndTime = request.getReqBody().getTill();
> - if (krbEndTime == null) {
> + if (krbEndTime == null || krbEndTime.getTime() == 0) {
> krbEndTime =
> krbStartTime.extend(config.getMaximumTicketLifetime()
> } else if (krbStartTime.greaterThan(krbEndTime)) {
> throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Yes, it looks like a good fix, 0 is there instead of null, for time fields in kdc request. Would you double check other time values by the way? Thanks!
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, April 21, 2015 7:11 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
The problem above is that the "end time" is 0 instead of "null". What do you think of this patch?
diff --git a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
--- a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++ b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime = krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
The problem above is that the "end time" is 0 instead of "null". What do
you think of this patch?
diff --git
a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb
index 3d49af3..23275fc 100644
---
a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
+++
b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server
@@ -370,7 +370,7 @@ public abstract class KdcRequest {
}
KerberosTime krbEndTime = request.getReqBody().getTill();
- if (krbEndTime == null) {
+ if (krbEndTime == null || krbEndTime.getTime() == 0) {
krbEndTime =
krbStartTime.extend(config.getMaximumTicketLifetime()
} else if (krbStartTime.greaterThan(krbEndTime)) {
throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
Colm.
On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> Hi Kai,
>
> 2. Please disable preauth in KDC side or require preauth in client
>> side. Looks like client didn’t send preauth data but KDC required it.
>>
>
> Ok I got a bit further by doing this. However, from what I can find out,
> the GSS client code should be sending the Pre authentication data (and
> there appears to be no option to disable it). So I think there may be a bug
> in how Kerby is processing the header? Should we log a JIRA to track this?
>
> The error I now get (when disabling pre auth in Kerby) is:
>
> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
> than end time
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
> at
> org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
>
> Any ideas? The Kerby server + CXF client are both on the same machine...
>
> Colm.
>
>
>>
>>
>> If you don’t want to trouble with the config stuff, please just change
>> the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Tuesday, April 21, 2015 6:34 PM
>> *To:* Apache Directory Developers List
>> *Subject:* Re: Kerby GSS tests?
>>
>>
>>
>> Actually I spoke too soon, I do know how to reproduce the
>> "pre-authentication" error. Simply uncomment the line
>> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
>> put a printStackTrace in the NettyKdcServerImpl, I see:
>>
>> Error occured while processing request:Generic error (description in
>> e-text)
>> SocketTimeOutException with attempt: 2
>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
>> #bytes=169
>> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
>> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
>> 127.0.0.1:43973 => /127.0.0.1:9002]
>> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
>> (description in e-text)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
>> at
>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
>> at
>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <
>> coheigea@apache.org> wrote:
>>
>> Hi Kai,
>>
>> Thanks for your response. I have a test-case of sorts that shows the
>> interop failure (although I can't reproduce the issue I reported yesterday
>> about the preauthentication data).
>>
>>
>> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>>
>> Run it with "mvn clean install". You may need the install the parent
>> module as well before running this, which is one level up.
>>
>> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
>> client API to successfully communicate with it. Then I have a Apache
>> CXF-based test which uses the Kerberos functionality here (based on GSS) to
>> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
>> output looks like:
>>
>> Loaded from Java config
>> >>> KdcAccessibility: reset
>> >>> KdcAccessibility: reset
>> Using builtin default etypes for default_tkt_enctypes
>> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>> >>> KrbAsReq creating message
>> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
>> retries =3, #bytes=169
>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
>> #bytes=169
>> java.net.SocketTimeoutException: Read timed out
>> at java.net.SocketInputStream.socketRead0(Native Method)
>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> at java.net.SocketInputStream.read(SocketInputStream.java:210)
>> at java.io.DataInputStream.readInt(DataInputStream.java:387)
>> at
>> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
>> at
>> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:745)
>> >>>DEBUG: TCPClient could not read length field
>> >>> KrbKdcReq send: #bytes read=0
>>
>> Any ideas?
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>>
>> Hi Colm,
>>
>>
>>
>> We haven’t any test for GSS client against Kerby yet, though we do have
>> tests in protocol level for ApReq (in kerb-core-test module). We might look
>> at existing ApacheDS Kerberos codes to see if any such end to end tests to
>> port.
>>
>>
>>
>> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
>> to be done yet. I originally got them done some days ago, but recently I
>> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
>> would be good to record them.
>>
>>
>>
>> For the issue you ran into, do you have test codes to repeat it, so we
>> may have the chance to look at it? Thanks.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Monday, April 20, 2015 10:40 PM
>> *To:* Apache Directory Developers List
>> *Subject:* Kerby GSS tests?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Are there any tests in the source (or has anyone successfully tested) a
>> Java GSS client -> Apache Kerby?
>>
>> The first issue I ran into was that neither the KdcNetwork nor the
>> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
>> fix it)?
>>
>> I could work around the above by setting "udp_preference_limit = 1".
>> However, I then run into an issue where it fails due to no
>> pre-authentication data in the request. Are we sure that this parsing is
>> working correctly?
>>
>> Colm.
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
You’re right. I just logged the following issue to fix it:
[jira] [Created] (DIRKRB-235) Handling krb errors and respond correctly
>> org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
Would you add a log to display what’s the mentioned time values? Or a debug? Thanks.
Note I’m going to add an end to end test per your suggestion, in https://issues.apache.org/jira/browse/DIRKRB-232.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, April 21, 2015 7:01 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
Ok I got a bit further by doing this. However, from what I can find out, the GSS client code should be sending the Pre authentication data (and there appears to be no option to disable it). So I think there may be a bug in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later than end time
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Kai,
2. Please disable preauth in KDC side or require preauth in client
> side. Looks like client didn’t send preauth data but KDC required it.
>
Ok I got a bit further by doing this. However, from what I can find out,
the GSS client code should be sending the Pre authentication data (and
there appears to be no option to disable it). So I think there may be a bug
in how Kerby is processing the header? Should we log a JIRA to track this?
The error I now get (when disabling pre auth in Kerby) is:
org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later
than end time
at
org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376)
at
org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96)
at
org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
at
org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51)
Any ideas? The Kerby server + CXF client are both on the same machine...
Colm.
>
>
> If you don’t want to trouble with the config stuff, please just change the
> default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Tuesday, April 21, 2015 6:34 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby GSS tests?
>
>
>
> Actually I spoke too soon, I do know how to reproduce the
> "pre-authentication" error. Simply uncomment the line
> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
> put a printStackTrace in the NettyKdcServerImpl, I see:
>
> Error occured while processing request:Generic error (description in
> e-text)
> SocketTimeOutException with attempt: 2
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
> #bytes=169
> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
> 127.0.0.1:43973 => /127.0.0.1:9002]
> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
> (description in e-text)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
> at
> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
> at
> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
> wrote:
>
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
>
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
1. Would you please update the codes to include some fixes we did today. But they may not relate to this issue, so see next;
2. Please disable preauth in KDC side or require preauth in client side. Looks like client didn’t send preauth data but KDC required it.
If you don’t want to trouble with the config stuff, please just change the default value of PREAUTH_REQUIRED in krb/kdc config key enumeration.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Tuesday, April 21, 2015 6:34 PM
To: Apache Directory Developers List
Subject: Re: Kerby GSS tests?
Actually I spoke too soon, I do know how to reproduce the "pre-authentication" error. Simply uncomment the line "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, #bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /127.0.0.1:43973<http://127.0.0.1:43973> => /127.0.0.1:9002<http://127.0.0.1:9002>]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error (description in e-text)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>> wrote:
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the interop failure (although I can't reproduce the issue I reported yesterday about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby client API to successfully communicate with it. Then I have a Apache CXF-based test which uses the Kerberos functionality here (based on GSS) to get a service ticket. If I put printStackTrace in the DefaultKdcHandler the output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, #bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com>> wrote:
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Actually I spoke too soon, I do know how to reproduce the
"pre-authentication" error. Simply uncomment the line
"kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I
put a printStackTrace in the NettyKdcServerImpl, I see:
Error occured while processing request:Generic error (description in e-text)
SocketTimeOutException with attempt: 2
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3,
#bytes=169
Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info
INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, /
127.0.0.1:43973 => /127.0.0.1:9002]
org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error
(description in e-text)
at
org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255)
at
org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94)
at
org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77)
Colm.
On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <co...@apache.org>
wrote:
> Hi Kai,
>
> Thanks for your response. I have a test-case of sorts that shows the
> interop failure (although I can't reproduce the issue I reported yesterday
> about the preauthentication data).
>
>
> https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
>
> Run it with "mvn clean install". You may need the install the parent
> module as well before running this, which is one level up.
>
> The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
> client API to successfully communicate with it. Then I have a Apache
> CXF-based test which uses the Kerberos functionality here (based on GSS) to
> get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
> output looks like:
>
> Loaded from Java config
> >>> KdcAccessibility: reset
> >>> KdcAccessibility: reset
> Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
> >>> KrbAsReq creating message
> >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
> retries =3, #bytes=169
> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
> #bytes=169
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
> at
> org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> >>>DEBUG: TCPClient could not read length field
> >>> KrbKdcReq send: #bytes read=0
>
> Any ideas?
>
> Colm.
>
> On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
>
>> Hi Colm,
>>
>>
>>
>> We haven’t any test for GSS client against Kerby yet, though we do have
>> tests in protocol level for ApReq (in kerb-core-test module). We might look
>> at existing ApacheDS Kerberos codes to see if any such end to end tests to
>> port.
>>
>>
>>
>> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
>> to be done yet. I originally got them done some days ago, but recently I
>> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
>> would be good to record them.
>>
>>
>>
>> For the issue you ran into, do you have test codes to repeat it, so we
>> may have the chance to look at it? Thanks.
>>
>>
>>
>> Regards,
>>
>> Kai
>>
>>
>>
>> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> *Sent:* Monday, April 20, 2015 10:40 PM
>> *To:* Apache Directory Developers List
>> *Subject:* Kerby GSS tests?
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Are there any tests in the source (or has anyone successfully tested) a
>> Java GSS client -> Apache Kerby?
>>
>> The first issue I ran into was that neither the KdcNetwork nor the
>> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
>> fix it)?
>>
>> I could work around the above by setting "udp_preference_limit = 1".
>> However, I then run into an issue where it fails due to no
>> pre-authentication data in the request. Are we sure that this parsing is
>> working correctly?
>>
>> Colm.
>>
>>
>>
>> --
>>
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby GSS tests?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Kai,
Thanks for your response. I have a test-case of sorts that shows the
interop failure (although I can't reproduce the issue I reported yesterday
about the preauthentication data).
https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby
Run it with "mvn clean install". You may need the install the parent module
as well before running this, which is one level up.
The test sets up a Kerby server, and I have a @Ignore'd test using Kerby
client API to successfully communicate with it. Then I have a Apache
CXF-based test which uses the Kerberos functionality here (based on GSS) to
get a service ticket. If I put printStackTrace in the DefaultKdcHandler the
output looks like:
Loaded from Java config
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23 1 3.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of
retries =3, #bytes=169
>>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1,
#bytes=169
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at
org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54)
at
org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
>>>DEBUG: TCPClient could not read length field
>>> KrbKdcReq send: #bytes read=0
Any ideas?
Colm.
On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <ka...@intel.com> wrote:
> Hi Colm,
>
>
>
> We haven’t any test for GSS client against Kerby yet, though we do have
> tests in protocol level for ApReq (in kerb-core-test module). We might look
> at existing ApacheDS Kerberos codes to see if any such end to end tests to
> port.
>
>
>
> You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are
> to be done yet. I originally got them done some days ago, but recently I
> was extremely busy with other projects, so kinds of delayed. Sure JIRAs
> would be good to record them.
>
>
>
> For the issue you ran into, do you have test codes to repeat it, so we may
> have the chance to look at it? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Monday, April 20, 2015 10:40 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby GSS tests?
>
>
>
> Hi all,
>
>
>
> Are there any tests in the source (or has anyone successfully tested) a
> Java GSS client -> Apache Kerby?
>
> The first issue I ran into was that neither the KdcNetwork nor the
> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to
> fix it)?
>
> I could work around the above by setting "udp_preference_limit = 1".
> However, I then run into an issue where it fails due to no
> pre-authentication data in the request. Are we sure that this parsing is
> working correctly?
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby GSS tests?
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Colm,
We haven’t any test for GSS client against Kerby yet, though we do have tests in protocol level for ApReq (in kerb-core-test module). We might look at existing ApacheDS Kerberos codes to see if any such end to end tests to port.
You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are to be done yet. I originally got them done some days ago, but recently I was extremely busy with other projects, so kinds of delayed. Sure JIRAs would be good to record them.
For the issue you ran into, do you have test codes to repeat it, so we may have the chance to look at it? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Monday, April 20, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Kerby GSS tests?
Hi all,
Are there any tests in the source (or has anyone successfully tested) a Java GSS client -> Apache Kerby?
The first issue I ran into was that neither the KdcNetwork nor the NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to fix it)?
I could work around the above by setting "udp_preference_limit = 1". However, I then run into an issue where it fails due to no pre-authentication data in the request. Are we sure that this parsing is working correctly?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com