Discussion:
create krb5 context without config files
Bin Lu
2014-06-10 18:48:28 UTC
Permalink
Hi,

Is there a way to create a krb5 lib context without using any config files, include /etc/krb5.conf and files set in environmental variables? Assume the realm/domain and kdc server info is already available.

Thanks,
-binlu
Benjamin Kaduk
2014-06-11 03:21:33 UTC
Permalink
Post by Bin Lu
Hi,
Is there a way to create a krb5 lib context without using any config
files, include /etc/krb5.conf and files set in environmental variables?
Assume the realm/domain and kdc server info is already available.
For this I think you need to use krb5_init_context_profile(), with a
profile derived from profile_init_vtable() (see <profile.h>).

I see that your previous message did not get answered, but it looks like
if you are asking this question, you have gotten past it. I will note
that the server doing password verification will need to have kerberos
credentials of its own and take care to avoid the Zanarotti attack.

-Ben Kaduk
Bin Lu
2014-06-12 19:09:48 UTC
Permalink
Hi Ben,

Thank you very much for your response.

Krb5_init_context_profile() seems to init a context from an existing profile which could be retrieved from krb5_get_profile(). profile_init_vtable() is not a public API, so should not be recommended to use.

Seems there isn't any other API to create a Kerberos context without using config files. Could you please confirm?

Thanks,
-binlu

-----Original Message-----
From: Benjamin Kaduk [mailto:***@MIT.EDU]
Sent: Tuesday, June 10, 2014 8:22 PM
To: Bin Lu
Cc: ***@mit.edu
Subject: Re: create krb5 context without config files
Post by Bin Lu
Hi,
Is there a way to create a krb5 lib context without using any config
files, include /etc/krb5.conf and files set in environmental variables?
Assume the realm/domain and kdc server info is already available.
For this I think you need to use krb5_init_context_profile(), with a profile derived from profile_init_vtable() (see <profile.h>).

I see that your previous message did not get answered, but it looks like if you are asking this question, you have gotten past it. I will note that the server doing password verification will need to have kerberos credentials of its own and take care to avoid the Zanarotti attack.

-Ben Kaduk
Benjamin Kaduk
2014-06-12 20:18:50 UTC
Permalink
Post by Bin Lu
Hi Ben,
Thank you very much for your response.
Krb5_init_context_profile() seems to init a context from an existing
profile which could be retrieved from krb5_get_profile().
profile_init_vtable() is not a public API, so should not be recommended
to use.
I am not sure why you think that profile_init_vtable() is not a public
API; it is listed in the public header that is installed.
(Okay, it was not listed in libkrb5.exports until relatively recently, but
that was an omission that should be fixed in 1.12.2.)
It is intended to be a public API.

-Ben
Post by Bin Lu
Seems there isn't any other API to create a Kerberos context without
using config files. Could you please confirm?
Greg Hudson
2014-06-12 20:39:37 UTC
Permalink
Post by Bin Lu
Krb5_init_context_profile() seems to init a context from an existing profile which could be retrieved from krb5_get_profile(). profile_init_vtable() is not a public API, so should not be recommended to use.
It was just an oversight that we didn't add profile_init_vtable to the
libkrb5 export list. As Ben said, it should be fixed in 1.12.2.
Post by Bin Lu
Seems there isn't any other API to create a Kerberos context without using config files. Could you please confirm?
At the moment, yes. I would like it to be possible to create an
in-memory empty profile and then set values on it with
profile_add_relation, but we haven't implemented it yet.
Nico Williams
2014-06-13 01:36:14 UTC
Permalink
It would be nice if the libraries could work with zero configuration.
It should be doable.

KDCs can be found via DNS.

[capaths] is mostly not needed on client sides, and if the KDC sets
the transit-policy-checked bit on tickets then it's also not needed on
servers (or if hierarchical transit paths are used). (Obviously
servers can't be entirely zero-conf: they need keytabs, or TGTs for
user-to-user, but still, not needing a krb5.conf is nice.)

Default realm is only needed in some cases. It should either be
derived from the host's domainname, from the default ccache's default
principal's realm or left unset.

If a user kinits without a realm name then kinit should either fail in
zero-conf more or it should insist on DNSSEC for discovery of a
default realm or it should trust the host's fqdn or it should ask the
user to confirm the realm.

Zero-conf aname2lname is a bit of an oxymoron, so zero-conf -> no
aname2lname, IMO.

Zero-conf / minimal-conf Kerberos is clearly feasible, and there's
value in it. IMO it should be done. (The Solaris Kerberos team put
some effort into it, BTW.)

Nico
--
Benjamin Kaduk
2014-06-13 01:38:02 UTC
Permalink
Post by Nico Williams
It would be nice if the libraries could work with zero configuration.
It should be doable.
We ship an empty krb5.ini for KfW 4.x, which seems to work.

-Ben
Nico Williams
2014-06-13 01:53:36 UTC
Permalink
Oh, did I conflate "zero-conf" with "ignore-conf"?

Loading...