This commit adds support for kx509 in libkrb5, and revamps the KDC's
kx509 service (fixing bugs, adding features).
Of note is that kx509 is attempted optimistically by the client, with
the certificate and private key stored in the ccache, and optionally in
an external PEM or DER file.
NOTE: We do not optimistically use kx509 in krb5_cc_store_cred() if the
ccache is a MEMORY ccache so we don't generate a key when
accepting a GSS context with a delegated credential.
kx509 protocol issues to be fixed in an upcoming commit:
- no proof of possession (this is mostly not too bad, but we'll want to
fix it by using CSRs)
- no algorithm agility (only plain RSA is supported)
- very limited (no way to request any options in regards to the
requested cert)
- error codes are not very useful
Things we're adding in this commit:
- libkrb5 kx509 client
- automatic kx509 usage hooked in via krb5_cc_store_cred() of start TGT
- per-realm templates on the KDC side
- per-realm issuer certificates
- send error messages on the KDC side
(this is essential to avoid client-side timeouts on error)
- authenticate as many error messages
- add a protocol probe feature so we can avoid generating a
keypair if the service is not enabled
(once we add support for ECC algorithms we won't need this
anymore; the issue is that RSA keygen is slow)
- support for different types of client principals, not just username:
- host-based service and domain-based service, each with its own
template set per-{realm, service} or per-service
(the idea is to support issuance of server certificates too, not
just client/user certs)
- more complete support for SAN types
- tests (including that PKINIT->kx509->PKINIT works, which makes it
possible to have "delegation" of PKIX credentials by just delegating
Kerberos credentials)
- document the protocol in lib/krb5/kx509.c
Future work:
- add option for longer-ticket-lifetime service certs
- add support for ECDSA, and some day for ed25519 and ed448
- reuse private key when running kinit
(this will require rethinking how we trigger optimistic kx509
usage)
- HDB lookup for:
- optional revocation check (not strictly necessary)
- adding to certificates those SANs listed in HDB
- hostname aliases (dNSName SANs)
- rfc822Name (email)
- XMPP SANs
- id-pkinit-san (a user could have aliases too)
- support username wild-card A RRs, ala OSKT/krb5_admin
i.e., if a host/f.q.d.n principal asks for a certificate for
some service at some-label.f.q.d.n, then issue it
(this is not needed at OSKT sites because OSKT already
supports keying such service principals, which means kx509
will issue certificates for them, however, it would be nice
to be able to have this independent of OSKT)
(a better way to do this would be to integrate more of OSKT
into Heimdal proper)
- a kx509 command, or heimtools kx509 subcommand for explicitly
attempting use of the kx509 protocol (as opposed to implicit, as is
done in kinit via krb5_cc_store_cred() magic right now)
Issues:
- optimistically trying kx509 on start realm TGT store -> timeout issues!
- newer KDCs will return errors because of this commit; older ones
will not, which causes timouts
- need a separate timeout setting for kx509 for optimistic case
- need a [realm] config item and DNS SRV RR lookup for whether a
realm is expected to support kx509 service
Note that this has a slight behavior change to c89d3f3b in order to continue
allow kadmin in local mode to bypass password quality checks. Password quality
checks are always bypassed if the *client* kadmin principal is kadmin/admin,
i.e. that of the kadmin service itself. This is the case when running kadmin in
local mode. As this is the equivalent of a superuser account, one would
anticipate that deployments would use specific administrator instances for
appropriate ACLs for day-to-day administration; operations by these will be
subject to password quality checks if enforce_on_admin_set is TRUE, or if the
user is changing their own password.
This patch adds the "enforce_on_admin_set" configuration knob in the
[password_quality] section. When this is enabled, administrative password
changes via the kadmin or kpasswd protocols will be subject to password quality
checks. (An administrative password change is one where the authenticating
principal is different to the principal whose password is being changed.)
Note that kadmin running in local mode (-l) is unaffected by this patch.
cf/make-proto.pl copies Doxygen docs to -private and -protos headers.
We need to either extract these from those files but not source files,
or only from source files but not the generated headers. This commit
does the latter.
For hx509.texi, we need the copyright macros for both html and info.
Just remove the "ifhtml" conditionals.
For whatis.texi, texinfo 5.1 inserts the sub{} macro inline with no
newlines, so there are errors about @html not being at the end of a
line, etc.
The ipropd_slave will log its status to /var/heimdal/ipropd-slave-status
if its connecting, up to date, or disconnected.
The master will now also confirm to slaves that are are in fact up to date
if they just restart, before there was no confirmation, the slave just didn't
get any deltas.
[Code reviewed by Love Hörnquist Åstrand <lha@kth.se>]
Added heim_db_*() entry points for dealing with databases, and
make krb5_aname_to_localname() use it.
The following enhancements to libheimbase are included:
- Add heim_data_t and heim_string_t "reference" variants to
avoid memory copies of potentially large data/strings.
See heim_data_ref_create() and heim_string_ref_create().
- Added enhancements to heim_array_t to allow their use for
queues and stacks, and to improve performance. See
heim_array_insert_value().
- Added XPath-like accessors for heim_object_t. See
heim_path_get(), heim_path_copy(), heim_path_create(), and
heim_path_delete(). These are used extensively in the DB
framework's generic composition of ACID support and in the
test_base program
- Made libheimbase more consistent with Core Foundation naming
conventions. See heim_{dict, array}_{get, copy}_value() and
heim_path_{get, copy}().
- Added functionality to and fixed bugs in base/json.c:
- heim_serialize();
- depth limit for JSON parsing (for DoS protection);
- pretty-printing;
- JSON compliance (see below);
- flag options for parsing and serializing; these are needed
because of impedance mismatches between heim_object_t and
JSON (e.g., heim_dict_t allows non-string keys, but JSON
does not; heimbase supports binary data, while JSON does
not).
- Added heim_error_enomem().
- Enhanced the test_base program to test new functionality and
to use heim_path*() to better test JSON encoding. This
includes some fuzz testing of JSON parsing, and running the
test under valgrind.
- Started to add doxygen documentation for libheimbase (but doc
build for libheimbase is still incomplete).
Note that there's still some incomplete JSON support:
- JSON string quoting is not fully implemented;
- libheimbase lacks support for real numbers, while JSON has
it -- otherwise libheimbase is a superset of JSON,
specifically in that any heim_object_t can be a key for an
associative array.
The following DB backends are supported natively:
- "sorted-text", a binary search of sorted (in C locale), flat
text files;
- "json", a backend that stores DB contents serialized as JSON
(this is intended for configuration-like contents).
The DB framework supports:
- multiple key/value tables per-DB
- ACID transactions
The DB framework also natively implements ACID transactions for
any DB backends that a) do not provide transactions natively, b)
do provide lock/unlock/sync methods (even on Windows). This
includes autocommit of DB updates outside transactions.
Future DB enhancements may include:
- add backends for various DB types (BDB, CDB, MDB, ...);
- make libhdb use heim_db_t;
- add a command-line tool for interfacing to databases via
libheimbase (e.g., to get/set/delete values, create/copy/
backup DBs, inspect history, check integrity);
- framework-level transaction logging (with redo and undo
logging), for generic incremental replication;
- framework-level DB integrity checking.
We could store a MAC of the XOR of a hash function applied to
{key, value} for every entry in the DB, then use this to check
DB integrity incrementally during incremental replication, as
well as for the whole DB.
