directory-dev 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 Tue, 21 Apr 2015 12:52:33 GMT
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>
wrote:

>
>
> On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <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]
>> *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> wrote:
>>
>>
>>
>> Yep I will do!
>>
>> Colm.
>>
>>
>>
>> On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <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]
>> *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> 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]
>> *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 <
>> 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> 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]
>> *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

Mime
View raw message