directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Kerby GSS tests?
Date Wed, 29 Apr 2015 10:37:59 GMT
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.zheng@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
> <mailto: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<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.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
> <mailto:service.ws.apache.org@service.ws.apache.org>";
>
> From: Zheng, Kai [mailto:kai.zheng@intel.com<mailto:kai.zheng@intel.com>]
> Sent: Friday, April 24, 2015 8:12 PM
> To: coheigea@apache.org<mailto: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 <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
> <mailto:service.ws.apache.org@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <mailto:service.ws.apache.org@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <mailto:service.ws.apache.org@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <mailto:service.ws.apache.org@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <mailto:service.ws.apache.org@service.ws.apache.org>
> Found KerberosKey for bob/service.ws.apache.org@service.ws.apache.org
> <mailto: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<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<mailto:kai.zheng@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<mailto:kai.zheng@intel.com>]
> Sent: Thursday, April 23, 2015 7:10 PM
>
> To: coheigea@apache.org<mailto: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<mailto: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 <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<mailto:krbtgt@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
> <mailto: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 <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<mailto: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 <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<mailto:kai.zheng@intel.com>]
> Sent: Wednesday, April 22, 2015 10:46 PM
>
> To: coheigea@apache.org<mailto: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 <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 <drankye@gmail.com<mailto:drankye@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<mailto:kai.zheng@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<mailto: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<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
> <mailto:kayyagari@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
> <mailto:coheigea@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
> <mailto: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<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
> <mailto: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 <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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message