[18845] in Kerberos_V5_Development
Re: create krb5 context without config files
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jun 12 21:36:34 2014
MIME-Version: 1.0
In-Reply-To: <539A1009.3030705@mit.edu>
Date: Thu, 12 Jun 2014 20:36:14 -0500
Message-ID: <CAK3OfOhLmmZx9=JDa6qjdL2y6PrZQn+CC-eEzUBmmqk+t04=mA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
