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]> 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
