GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

JSoet
Hi, I'm implementing SPNEGO & Kerberos authentication in our application's webserver code and have it working fine when the KDC is Active Directory. I'm now testing it with an MIT KDC instance and when I attempt to authenticate a user who has a ticket from that KDC I get a GSS_S_CONTINUE_NEEDED status when I call gss_accept_sec_context...

My understanding was that this couldn't happen for kerberos authentication though, and the GSS_S_CONTINUE_NEEDED is only for other potential authentication types. For example, when I was investigating other implementations the mod_auth_kerb module in the apache webserver and the kerberos module for the flask webserver both ignore the possibility of continuation and in the apache webserver it has this comment "This is a _Kerberos_ module so multiple authentication rounds aren't supported. If we wanted a generic GSS authentication we would have to do some magic with exporting context etc."

I haven't tried to implement the continuation of the context yet, because it will be a fair amount of work, so I thought I'd email the group to ask whether it's likely that there is just a problem with my setup, or if I'm mistaken and it is possible to get a continue_needed when working with Kerberos?

Thanks,
Jordan
Reply | Threaded
Open this post in threaded view
|

Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

Rick van Rein (OpenFortress)
Jordan,

> I haven't tried to implement the continuation of the context yet, because it
> will be a fair amount of work, so I thought I'd email the group to ask
> whether it's likely that there is just a problem with my setup, or if I'm
> mistaken and it is possible to get a continue_needed when working with
> Kerberos?

Have you had a look at the data that is actually exchanged?  SPNEGO is a
switch between mechanisms and may decide to change to another mechanism, for
whatever reason, including failure to use your MIT krb5 system.  But it
might also prefer to attempt another mechanism (or maybe none) initially.

You are correct that SPNEGO can make an educated guess and attach one
possible mechanism's output along with the SPNEGO bytes, in the hope
that it passes through directly; with Kerberos, that would mean that
it one exchange suffices.  But SPNEGO may have other things on its
mind as well.

So, you should have a look at what travels between the peers.

-Rick

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

JSoet

> So, you should have a look at what travels between the peers.

Thanks, Rick, I looked into it, but my negotiate messages look like this:

"Negotiate YIID..." which I think means that they're kerberos messages? Anyone have any other ideas of what could be causing the continue_needed message then? Could it be something with the DNS, I'm not really that confident of my DNS setup, but don't really know what to look into to determine if it's properly set up? (Although I also have ignore_acceptor_hostname = true and I'm passing GSS_C_NO_CREDENTIAL to gss_accept_sec_context, so I'm not sure if that even matters?)

I also noticed that if I switch the server back as it was before (with the keytab for the service principal of the Active Directory kdc, and the previous hostname, although with the krb5.conf still pointing at both realms) and then try and do a login when I have a ticket of one of the users from the new MIT realm it also gives me a continue_needed, so could it be something to do with the tickets themselves? I've noticed that the tickets 'renew until' time is already passed (but the tickets don't expire until 12 hrs in the future), but I'm not sure what to change to make the renew time longer, the krb5.conf on the client has renew_lifetime set as 7d... And in the kdc.conf on the kdc server the max_renewable_life is set as 5d... ?

Reply | Threaded
Open this post in threaded view
|

Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

Benjamin Kaduk-2
In reply to this post by JSoet
On Thu, 25 Aug 2016, JSoet wrote:

> Hi, I'm implementing SPNEGO & Kerberos authentication in our application's
> webserver code and have it working fine when the KDC is Active Directory.
> I'm now testing it with an MIT KDC instance and when I attempt to
> authenticate a user who has a ticket from that KDC I get a
> GSS_S_CONTINUE_NEEDED status when I call gss_accept_sec_context...
>
> My understanding was that this couldn't happen for kerberos authentication
> though, and the GSS_S_CONTINUE_NEEDED is only for other potential
> authentication types. For example, when I was investigating other
> implementations the mod_auth_kerb module in the apache webserver and the
> kerberos module for the flask webserver both ignore the possibility of
> continuation and in the apache webserver it has this comment "This is a
> _Kerberos_ module so multiple authentication rounds aren't supported. If we
> wanted a generic GSS authentication we would have to do some magic with
> exporting context etc."

Some non-krb5 GSS mechanisms require multiple calls to
gss_accept_sec_context(); likewise if the negotiation portion of SPNEGO is
used (i.e., the client picks something that the server won't do).  But
it's hard to diagnose from just what has been said so far.  I would try
running the server with KRB5_TRACE set in the environment (a path to a log
file) and see if the trace output helps make things clear.  Otherwise,
it's probably going to be a matter of dissecting the actual protocol
messages exchanged, seeing what OIDs are sent, etc.

-Ben
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

Rick van Rein (OpenFortress)
In reply to this post by JSoet
Hi Jordan,

> I looked into it, but my negotiate messages look like this:
>
> "Negotiate YIID..." which I think means that they're kerberos messages?

You should base64-decode it [Section 4.1 of RFC 4559] and dump that as GSSAPI content which, at least in this early phase, is DER-encode.  You should make a dump of the decoded binary content with a tool like "openssl asn1parse" with a few layout options or, for much more/better information, with my Python script on https://github.com/vanrein/hexio/blob/master/derdump

There will be a number of OIDs to signal content following; these you can lookup on duckduckgo.com.  You should see a general offer packet providing the available mechanisms, followed by one that it takes a proactive guess it -- normally Kerberos.

If you're still confused, you could also try sending the output here.

-Rick
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

JSoet
Thanks for the help, when I looked at the output, it contained mech
1.3.6.1.5.2.5 which I guess is GSS_IAKERB_MECHANISM ... Looking into that
I think I had a somewhat similar problem to this:
http://stackoverflow.com/questions/23759016/spnego-kerberos-no-credential-found-error-with-requests-from-linux-client

But it wasn't a problem with my reverse dns - that was set up properly,
but the problem was some errant capitalization of the service principal in
the kdc database. When I looked at the wireshark output I saw that it was
the TGS-REQ was failing with an "UNKNOWN_SERVER" error, and looking into
that a bit more I realized I had a problem with the name. When using AD I
had had a SPN with CamelCase and that hadn't caused a problem, but with
the MIT KDC it did, which was a stupid problem that I should've figured
out.

Thanks for your help :)

Thanks,

Jordan Weitman-Soet
Safer Payments Software Developer

Phone: 1-778-327-7338 | Tie-Line: 3177338 | Mobile: 1-778-867-5683
E-mail: [hidden email]


1190 Homer St Suite 401
Vancouver, BC V6B 2X6
Canada




From:   Rick van Rein <[hidden email]>
To:     Jordan Soet/CanWest/IBM@IBMCA
Cc:     [hidden email]
Date:   08/27/2016 05:03 AM
Subject:        Re: GSS_S_CONTINUE_NEEDED when doing Kerberos
authentication?



Hi Jordan,

> I looked into it, but my negotiate messages look like this:
>
> "Negotiate YIID..." which I think means that they're kerberos messages?

You should base64-decode it [Section 4.1 of RFC 4559] and dump that as
GSSAPI content which, at least in this early phase, is DER-encode.  You
should make a dump of the decoded binary content with a tool like "openssl
asn1parse" with a few layout options or, for much more/better information,
with my Python script on
https://github.com/vanrein/hexio/blob/master/derdump

There will be a number of OIDs to signal content following; these you can
lookup on duckduckgo.com.  You should see a general offer packet providing
the available mechanisms, followed by one that it takes a proactive guess
it -- normally Kerberos.

If you're still confused, you could also try sending the output here.

-Rick






________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos