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
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.
If there is no MSLSA: credential cache principal, then try to
fallback to the MIT default MIT credential cache name, API:krb5cc.
Change-Id: I8f981c5401b4f962cf808e7b0dc782e42bc03023
If there is no default credential cache obtained from the registry
or from configuration files, then check to see if there is a valid
principal available from the MSLSA: credential cache. If so, use
"MSLSA:" as the default credential cache. This will simply configuration
for users on domain joined Windows machines when logged in using a
domain account.
Change-Id: I4c4392e0fdcec89aff3d258ce1b753e6458e3eec
Remove unnecessary levels of indentation.
Switch the conditional from "(e == NULL)" to "(p == NULL)" since it
the variable 'p' that is actually used to store the name of the
default credential cache.
Change-Id: Id884e2cd80b42e47d3c219ac3777161087467a14
Windows queries the default ccache name via the registry. Prior
to this change only the HKEY_CURRENT_USER hive. Fallback to
HKEY_LOCAL_MACHINE if there is no "ccname" value specified for the
user. This permits system or domain administrators to set the
default ccache to MSLSA: for all users.
Change-Id: Ide3b51358f8fc6944ca698e4a68295be9463d4e0
Commit ad7e54d698 introduced the use
of _krb5_expand_path_tokens() to expand tokens (and on Windows convert
path delimiters) within credential cache names. This is safe to do
for the path based credential cache types FILE, DIR and SCC but on
Windows is unsafe for the non-path types.
For example on Windows, the API credential cache names are often based
on the principal name and the principal name is parsed from the ccname.
This practice was introduced with the version v2 ccapi when there was
no method of enumerating the caches from the krb5 library.
This change adds a "filepath" boolean parameter to _krb5_expand_path_tokens()
which is set to TRUE (non-zero) when the input is a file path and FALSE
(zero) when the input is not a file path. _krb5_expand_path_tokens() will
only perform directory separator normalization on Windows when the
"filepath" parameter is TRUE.
This change is not the preferred solution because it requires that the
library be aware of all credential cache types that use path based
residuals. The preferred solution would require that the credential cache
implementation indicate whether or not it uses a path based residual.
This change has been implemented using a prefix test and not a change to
struct krb5_cc_ops because existing ccache plugins will not know how to
advertise their use of path based residuals and that path expansion is
safe.
Change-Id: I8135991e8ce69fc5273d381ea9c2078bc2bcd19a
Windows treats '\\' and '/' equivalently but we cannot control
the form that will be used by end users. Introduce ISPATHSEP()
macro which tests only for '/' on UNIX and both on Windows.
Introduce ISTILDE() macro to test for '~'. When testing for
'/' with strchr() or strrchr() add conditional checks for '\\' on
Windows.
Change-Id: Ia85e698fc88f15a6a71db649db5417f02ef7e5fe
Add _krb5_set_default_cc_name_to_registry() function and
call use it on Windows to set the user's default credential cache.
Change-Id: Ib59ff218a098a841bc61846abf873736380b5c6c
On Windows, existing applications determine and change the default
credentials cache using the Kerberos for Windows registry key
(\Software\MIT\Kerberos5, ccname). Use it for backwards
compatibility.
On Windows, a pathname can contain a drive letter and a colon.
krb5_cc_resolve() used to check whether there were any colons in the
ccache name string and assume it is a FILE: cache if there weren't.
In addition, on Windows, check for a drive specification.
Appease the compiler by resolving some of the reported warnings,
including:
- Control paths that don't return.
- Potentially uninitialized variables.
- Unused local variables.
- Unreachable code.
- Type safety.
- Synchronize declarations with definitions for functions.
Don't make a copy of the krb5_cc_ops into krb5_context and hand that
out to callers of the api, this way its possible to free a krb5_context
w/o invalidating all krb5_ccaches that was allocated using that krb5_context
(also, it saves memory)
