bcb5ed28fb ("kdc/kx509.c: clean up
krb5_get_error_message strings used for mk_error_resp") introduced a
build failure. 'context' is not a local variable but a field in the
kx509_req_context.
Change-Id: I38a8a9b1a19c3370dfc039d6e09445425936c32b
mk_error_response expects the strings it builds will need to be freed but
not those passed in; krb5_get_error_message generates a string which needs to
be freed. keep track of and free those strings.
on error from der_parse_heim_old we early exit via out, which frees
s and cprinc; we should not do so a second time unless we explicitly
NULL the pointers but there is no value in doing so.
We define the meaning of the various log levels in the man page
for krb5_openlog(3). If logging configured and levels are not
specified, we change the default levels to 0-3 which should exclude
debugging messages which are generally only desired in exceptional
circumstances.
We also go through the KDC and adjust the levels to be appropriate.
This commit adds support for proof of posession to the kx509 protocol by
using PKCS#10 CSRs.
This allows conveyance of extReq CSR attributes requesting desired
Certificate Extensions.
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
Each KDC is a kx509 server. The service principal must be of the
form
kca_service/<localhost.domain>@<DEFAULT_REALM>
where localhost.domain is the hostname returned by gethostname()
and <DEFAULT_REALM> is one of the realms for which the KDC has a service
principal "kca_service/<localhost.domain>".
The matching code was broken by a5e77c578e
when krb5_sname_to_principal() began to always return a referral
principal.
Since the second component is a host name update the default principal
type for service "kca_service" to be KRB5_NT_SRV_HST.
Change-Id: I6bd5f90b674ebb7220d8efafa6d339fdc21e1a07
In _kdc_do_kx509() do not free 'principal' until after its last
use. Move declaration to top of function and free it during the
common exit processing.
Introduced by 10a5976e45.
Change-Id: Iaf000eb090b0fa523f04a4864c6b17058d922995
kx509 fails to create certs for principals with slashes in them. For
example:
client% kinit foo/admin
foo/admin@EXAMPLE.COM's Password:
client% kx509
Timed out waiting on KCA
The KCA reports: "Principal is not a user." However, there is a use
case set out in this post:
https://thestaticvoid.com/post/2012/10/25/protecting-puppet-with-kerberos/
that would create a kx509 cert for a host principal for authenticating
against a secure HTTP service. This commit modifies the certificate
creation code to allow principals with slashes in them.
