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 <kai.zh...@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:cohei...@apache.org] > Sent: Wednesday, April 29, 2015 6:38 PM > To: ke...@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 <kai.zh...@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:cohei...@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.zh...@intel.com > <mailto: > > kai.zh...@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....@service.ws.apache.org<mailto: > > service.ws.apache....@service.ws.apache.org>"); > > - > > + > > // Create principals > > String alice = "al...@service.ws.apache.org<mailto: > > al...@service.ws.apache.org>"; > > String bob = "bob/service.ws.apache....@service.ws.apache.org > > <mailto:service.ws.apache....@service.ws.apache.org>"; > > @@ -136,7 +134,7 @@ public class AuthenticationTest extends > > org.junit.Assert { > > } > > > > @org.junit.Test > > - @org.junit.Ignore > > + //@org.junit.Ignore<mailto://@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....@service.ws.apache.org<mailto: > > service.ws.apache....@service.ws.apache.org>"); > > - > > + > > // Create principals > > String alice = "al...@service.ws.apache.org<mailto: > > al...@service.ws.apache.org>"; > > String bob = "bob/service.ws.apache....@service.ws.apache.org > > <mailto:service.ws.apache....@service.ws.apache.org>"; > > > > From: Zheng, Kai > > [mailto:kai.zh...@intel.com<mailto:kai.zh...@intel.com>] > > Sent: Friday, April 24, 2015 8:12 PM > > To: cohei...@apache.org<mailto:cohei...@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:cohei...@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.zh...@intel.com<mailto: > > kai.zh...@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....@service.ws.apache.org > > <mailto:service.ws.apache....@service.ws.apache.org> > > Found KerberosKey for bob/service.ws.apache....@service.ws.apache.org > > <mailto:service.ws.apache....@service.ws.apache.org> > > Found KerberosKey for bob/service.ws.apache....@service.ws.apache.org > > <mailto:service.ws.apache....@service.ws.apache.org> > > Found KerberosKey for bob/service.ws.apache....@service.ws.apache.org > > <mailto:service.ws.apache....@service.ws.apache.org> > > Found KerberosKey for bob/service.ws.apache....@service.ws.apache.org > > <mailto:service.ws.apache....@service.ws.apache.org> > > Found KerberosKey for bob/service.ws.apache....@service.ws.apache.org > > <mailto:service.ws.apache....@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 al...@service.ws.apache.org<mailto: > > al...@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:cohei...@apache.org<mailto: > > cohei...@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.zh...@intel.com<mailto: > > kai.zh...@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:cohei...@apache.org<mailto: > > cohei...@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.zh...@intel.com<mailto: > > kai.zh...@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.zh...@intel.com<mailto:kai.zh...@intel.com>] > > Sent: Thursday, April 23, 2015 7:50 PM > > > > To: Apache Directory Developers List; cohei...@apache.org<mailto: > > cohei...@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:cohei...@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.zh...@intel.com > <mailto: > > kai.zh...@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.zh...@intel.com<mailto:kai.zh...@intel.com>] > > Sent: Thursday, April 23, 2015 7:10 PM > > > > To: cohei...@apache.org<mailto:cohei...@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:cohei...@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 " > > al...@service.ws.apache.org<mailto:al...@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.zh...@intel.com > <mailto: > > kai.zh...@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:cohei...@apache.org<mailto: > > cohei...@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 "krb...@example.com<mailto:krb...@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....@service.ws.apache.org > > <mailto:service.ws.apache....@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.zh...@intel.com > <mailto: > > kai.zh...@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: 'cohei...@apache.org<mailto:cohei...@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:cohei...@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.zh...@intel.com<mailto: > > kai.zh...@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:cohei...@apache.org<mailto: > > cohei...@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.zh...@intel.com<mailto: > > kai.zh...@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.zh...@intel.com<mailto:kai.zh...@intel.com>] > > Sent: Wednesday, April 22, 2015 10:46 PM > > > > To: cohei...@apache.org<mailto:cohei...@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:cohei...@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.zh...@intel.com<mailto: > > kai.zh...@intel.com>> wrote: > > Colm, > > > > Would you check out the fix below and verify it? Thanks! > > > > commit 41df0299ef254d877b6f570c1b71eb35c75e9fc5 > > Author: Drankye <dran...@gmail.com<mailto:dran...@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.zh...@intel.com<mailto:kai.zh...@intel.com>] > > Sent: Wednesday, April 22, 2015 8:36 PM > > To: Apache Directory Developers List; cohei...@apache.org<mailto: > > cohei...@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.zh...@intel.com] > > Sent: Wednesday, April 22, 2015 7:37 PM > > To: cohei...@apache.org<mailto:cohei...@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:cohei...@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: al...@service.ws.apache.org<mailto: > > al...@service.ws.apache.org> > > Client PRINC type: NT_PRINCIPAL > > Server PRINC: krbtgt/service.ws.apache....@service.ws.apache.org<mailto: > > service.ws.apache....@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....@service.ws.apache.org<mailto: > > service.ws.apache....@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.zh...@intel.com<mailto: > > kai.zh...@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:cohei...@apache.org<mailto: > > cohei...@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 <kayyag...@apache.org > > <mailto:kayyag...@apache.org>> wrote: > > > > > > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <kai.zh...@intel.com<mailto: > > kai.zh...@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:cohei...@apache.org<mailto: > > cohei...@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 < > cohei...@apache.org > > <mailto:cohei...@apache.org>> wrote: > > > > Yep I will do! > > Colm. > > > > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <kai.zh...@intel.com > <mailto: > > kai.zh...@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:cohei...@apache.org<mailto: > > cohei...@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 < > cohei...@apache.org > > <mailto:cohei...@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:cohei...@apache.org<mailto: > > cohei...@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 < > cohei...@apache.org > > <mailto:cohei...@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.zh...@intel.com > <mailto: > > kai.zh...@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:cohei...@apache.org<mailto: > > cohei...@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
