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
Now we'll use mkostemp() and rename() into place to make
hx509_certs_store() atomic for FILE/DER-FILE/PEM-FILE stores.
This is not ideal, as it can leave temp files in place if a process
crashes in between the mkostemp() and the rename into place.
On Linux we'll eventually make use of O_TMPFILE and linkat(). The idea
will be to first create an anonymous, zero-link file in the directory
that will contain the file at the end, write the file, then linkat() the
file into place as a .new file, then rename() the .new into place. That
will limit the amount of junk that may be left behind to just one file.
(If the linkat() fails, then unlink() the .new and try again. If the
rename() fails that just means the caller raced with another and the
operation is complete.)
We should really make a lib/roken interface that does this.
Prior to this commit the Heimdal ASN.1 compiler supported DEFAULTing
SEQUENCE fields on the encoder side, but not the decoder side, where
ASN1_MISSING_FIELD would inevitably result when fields were defaulted.
This patch adds the missing decode-side support for DEFAULT.
This commit adds functions for finding OIDs by symbolic name, meaning by
their symbolic names given in the ASN.1 modules that define them.
TBD:
- Resolve OIDs to names.
- Support a file in /etc for additional OID resolution.
- Add support for resolving OID arc names.
This will help us generate a directory of OIDs from all the ASN.1
modules in lib/asn1, which will then help us create an hx509 API for
resolving OIDs to/from friendly names, which ultimately will help us
make hxtool more user-friendly.
When a slave is many diffs behind, send these in batches of up to
50, then handle other slaves.
This also implements a fast-path that makes incremental diffs faster
when the log has not rolled over.
Related code cleanup.
If a slave is slow to consume what the master sends it, the master can
block and all iprop operations with it.
With minimal effort we make the master async oriented.
ipropd-master sends AYT messages often as a result of a possibly-
transient error, but if the slave responds to such an AYT with I_HAVE,
then the same code path that failed will be executed on the master, and
if the error wasn't transient then we'll loop hard. So don't send an
I_HAVE in response to an AYT.
Refactor krb5_cc_set_default_name() by splitting out the part that looks
for a configured default ccache name. This will allow one to check if a
given ccache is a default ccache for a process ignoring KRB5CCNAME,
which might prove useful in the kx509 client.
Move init/copy/destroy fallback sequence from fcc_move() to
krb5_cc_move().
Make sure all backends's move() method calls krb5_cc_destroy() on the
source on success (and only on success).
In text_cc make sure that we can find in the destination the cred
stored into the source.
This is necessary in order to have more control over, e.g., template
certificates for kx509. But also it's good to have this more generally.
Some batteries not included. Specifically: no attempt is made to validate that
given KeyUsage values are compatible with the subjectPublicKey's alrogithm and
parameters.
```
hxtool request-create --subject=... \
--generate-key=... \
--key-bits=... \
--key=STORE \
store
```
wants to generate a key, store it in the location specified by the --key
argument, then read it back, then generate the CSR, and store it in
`store`.
But it didn't work because for generating a key this really wants the
`--key` argument to be a file path into which a raw DER-encoded RSA key
will be written (only RSA is supported, ay!), but for reading the key
back it uses `hx509_certs_init()`, which wants `TYPE:name` keystore
specification. A deadly embrace.
Now that we have improved libhx509 functionality for reading/writing
private keys from/to PEM files we use this functionality and require a
store type in the `--key=STORE` argument.
This commit adds:
- hx509_cert_init_private_key() for creating an hx509_cert object that
has just a private key
- hx509_cert_have_private_key_only() for checking whether an hx509_cert
object has just a private key
This also generalizes the get_key() internal function in hxtool, which
is tasked with reding or generating a private key for use in signing
CSRs. Now hxtool request-create can read/write private keys to/from PEM
files, not just DER files.
This is needed to support key types other than just RSA for CSRs and
certificates.
