[Freeipa-devel] Kerberos implementation issues

[Sumit Bose]

On Tue, Jun 21, 2011 at 04:48:08PM -0600, Pete Zaitcev wrote:
> On Tue, 21 Jun 2011 18:28:36 -0400
> Dmitri Pal <dpal at redhat.com> wrote:
> 
> Dear Dmitri, thanks for the reply. I am reading curl source code
> now and I notice the distinction between "Negotiate" that comes
> from SPNEGO, and "GSS-Negotiate". I'm looking for the definition
> of the latter.
> 
> > > I am working on adding authentication/authorization
> > > to Image Warehouse (a.k.a. iwhd). It uses HTTP protocol, implemented
> > > with GNU Microhttpd. [...]
> 
> > > So far, I gather that so-called "SPNEGO" protocol is what everyone
> > > uses (RFC 4178). It relies on GSS-API (2743/2744) and Kerberos (4121).
> > > There's also a "Kerberos on Widows" thing (4559), which actually
> > > defines the key pieces such as "WWW-Authenticate: Negotiate".
> 
> > What web server you are using? It is mostly something that is used
> > outside the application by the web server itself.
> 
> As I mentioned, iwhd relies on GNU Microhttpd library to implement
> a webserver.

According to http://www.gnu.org/software/libmicrohttpd/ there is only
"Support for basic and digest authentication (optional)". As Dmitri
already mentioned there is mod_auth_kerb for Apache which offers the
Negotiate. It does GSSAPI but can handle SPNEGO as well and can
authenticate an SPNEGO client if it can handle GSSAPI (SPNEGO is
basically used to choose between GSSAPI or NTLMSSP).

As long as GNU Microhttpd library does not support at least GSSAPI, but
SPNEGO would be important for Windows clients, or can use Apache's
mod_auth_kerb somehow, I would recommend like Dmitri to use an Apache in
front of iwhd and let Apache forward the principal of the authenticated
user in e.g. X_FORWARDED_USER header variable.

> 
> > Like with Apache you can use/configure mod_auth_kerb and if the client
> > is configured to negotiate kerberos and the apache server has a keytab
> > and an service principal (name) in KDC (freeIPA) you are all set.
> > This is how the Katello prototype has been set up.
> 
> I see, the vital part here is the need to register the service principal
> with the KDC. I was wondering about that too.

Yes, both the client/user principal and the service principal must be
know to the KDC so that both can trust each other. With freeIPA every
user automatically will have it's own principal and every server added
to the IPA domain (ipa-client-install or ipa host-add) gets a host
principal host/fully.qualified.domain.name at YOUR.KERBEROS.REALM. For a
web service you typically do not want to use the host principal but
create one for the specific service
HTTP/fully.qualified.domain.name at YOUR.KERBEROS.REALM with ipa
service-add.

If you don't have freeIPA but a plain KDC you have to use the kadmin
utility to create the principals (and their keys).

HTH

bye,
Sumit

> 
> > The transactions would require a state. You can try to do something that
> > we are planning to do in IPA to reduce the cost of the re-negotiation on
> > every request. We plan to use a cookie. But it all depends what are your
> > transactions are for. Do they define the "commit" boundaries or they are
> > just to reduce renegotiation?
> 
> I am somewhat disaffected with cookies, as they have a lot of
> weaknesses (usually).. Certainly, turning around the 401 replies costs
> a lot, but until I know for myself that it cannot be avoided (by posting
> Authenticate header preventively), I am going to examine the facts
> a little more. However, if FreeIPA team comes up with "standard"
> way to keep tickets in cookies, I would like to hear the details.
> 
> Thanks again,
> -- Pete