On Tue, Apr 21, 2015 at 8:52 PM, Colm O hEigeartaigh <[email protected]> wrote:
> Hi Kiran, > > > The enctypes should always be sorted from the most to least > strong/preferred on the server side > > Is there any existing code in Apache Directory along these lines? > yes, it is in KerberosUtils[1] see the cipherAlgoMap and the orderEtypesByStrength() method [1] http://svn.apache.org/repos/asf/directory/apacheds/trunk/kerberos-codec/src/main/java/org/apache/directory/shared/kerberos/KerberosUtils.java > > Colm. > > > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <[email protected]> > wrote: > >> >> >> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <[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]] >>> *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]> wrote: >>> >>> >>> >>> Yep I will do! >>> >>> Colm. >>> >>> >>> >>> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <[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]] >>> *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]> 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]] >>> *Sent:* Tuesday, April 21, 2015 6:34 PM >>> *To:* Apache Directory Developers List >>> *Subject:* Re: Kerby GSS tests? >>> >>> >>> >>> Actually I spoke too soon, I do know how to reproduce the >>> "pre-authentication" error. Simply uncomment the line >>> "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I >>> put a printStackTrace in the NettyKdcServerImpl, I see: >>> >>> Error occured while processing request:Generic error (description in >>> e-text) >>> SocketTimeOutException with attempt: 2 >>> >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, >>> #bytes=169 >>> Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info >>> INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, >>> /127.0.0.1:43973 => /127.0.0.1:9002] >>> org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error >>> (description in e-text) >>> at >>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255) >>> at >>> org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94) >>> at >>> org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77) >>> >>> Colm. >>> >>> >>> >>> On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh < >>> [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]> >>> 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]] >>> *Sent:* Monday, April 20, 2015 10:40 PM >>> *To:* Apache Directory Developers List >>> *Subject:* Kerby GSS tests? >>> >>> >>> >>> Hi all, >>> >>> >>> >>> Are there any tests in the source (or has anyone successfully tested) a >>> Java GSS client -> Apache Kerby? >>> >>> The first issue I ran into was that neither the KdcNetwork nor the >>> NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to >>> fix it)? >>> >>> I could work around the above by setting "udp_preference_limit = 1". >>> However, I then run into an issue where it fails due to no >>> pre-authentication data in the request. Are we sure that this parsing is >>> working correctly? >>> >>> Colm. >>> >>> >>> >>> -- >>> >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >>> >>> >>> -- >>> >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >>> >>> >>> -- >>> >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >>> >>> >>> -- >>> >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >>> >>> >>> -- >>> >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >>> >>> >>> -- >>> >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >>> >>> >>> -- >>> >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >> >> >> >> -- >> Kiran Ayyagari >> http://keydap.com >> > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > -- Kiran Ayyagari http://keydap.com
