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:[email protected]]
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
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
Sent: Wednesday, April 22, 2015 10:46 PM
To: [email protected]<mailto:[email protected]>
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:[email protected]]
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
<[email protected]<mailto:[email protected]>> wrote:
Colm,
Would you check out the fix below and verify it? Thanks!
commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5
Author: Drankye <[email protected]<mailto:[email protected]>>
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:[email protected]<mailto:[email protected]>]
Sent: Wednesday, April 22, 2015 8:36 PM
To: Apache Directory Developers List;
[email protected]<mailto:[email protected]>
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:[email protected]]
Sent: Wednesday, April 22, 2015 7:37 PM
To: [email protected]<mailto:[email protected]>
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:[email protected]]
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: [email protected]<mailto:[email protected]>
Client PRINC type: NT_PRINCIPAL
Server PRINC:
krbtgt/[email protected]<mailto:[email protected]>
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/[email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
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
<[email protected]<mailto:[email protected]>> wrote:
On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
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
<[email protected]<mailto:[email protected]>> wrote:
Yep I will do!
Colm.
On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
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
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
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
