We must switch to OpenSSL 3.x, and getting lib/hcrypto to provide
OpenSSL 3.x APIs is too large an undertaking. Plus the hcrypto backend
is not safe, not secure (probably has timing leaks galore), and no one
has the resources to make it a world-class crypto library, so it just
has to go.
Nowadays we use PACs instead of AD-SIGNEDPATH, so we want a PAC on every
TGT, but we don't necessarily want PACs on cross-realm TGTs.
Specifically, we don't interop well yet with AD when issuing cross-realm
TGTs with AD realms as the destination realm (see #1091).
We introduced a notion of soft vs. hard aliases in the previous commit
(hdb: Distinguish soft and hard principal aliases).
This commit corrects existing test cases and adds new test cases.
Soft aliases allow for the configuration of referrals using HDB entries.
Hard aliases are like copies of the aliased HDB entries. These are
useful for renaming principals (and realms).
See the preceding commit.
Add a new method for issuing referrals for entire namespaces of hostnames.
An alias of the form WELLKNOWN/HOSTBASED-NAMESPACE/service/namespace-fqdn@REALM
will cause all requests for host-based principals in the given namespace to be
referred to the given realm.
PACs are included when issuing TGTs, if there is no PAC_ATTRIBUTES buffer
(legacy behavior) or if the attributes buffer indicates the AS client requested
one.
KRB5SignedPath was a Heimdal-specific authorization data element used to
protect the authenticity of evidence tickets when used in constrained
delegation (without a Windows PAC).
Remove this, to be replaced with the Windows PAC which itself now supports
signing the entire ticket in the TGS key.
This was broken with KRB5SignedPath but now that we switch to PAC
we get it fixed without KDC changes, so we can just test it.
See also PR #599 from where these tests were taken.
This is useful for services that need not be clients. For example, an
untrusted service that need only accept authentication from clients,
but not initiate authentication to other services.
Anonymous PKINIT tickets discard the realm information used to locate the
issuing AS. Store the issuing realm in the credentials cache in order to locate
a KDC which can renew them.
even if tgt used an enctype with a different checksum.
Per [MS-SFU] 2.2.1 PA-FOR-USER the checksum is always
HMAC_MD5, and that's what Windows and MIT clients send.
In heimdal both the client and kdc use instead the
checksum of the tgt, and therefore work with each other
but windows and MIT clients fail against heimdal KDC.
Both Windows and MIT KDC would allow any keyed checksum
to be used so Heimdal client work fine against it.
Change Heimdal KDC to allow HMAC_MD5 even for non RC4
based tgt in order to support per-spec clients.
Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Commit f469fc6 (2010-10-02) inadvertently caused the previous hop realm
to not be added to the transit path of issued tickets. This may, in
some cases, enable bypass of capath policy in Heimdal versions 1.5
through 7.2.
Note, this may break sites that rely on the bug. With the bug some
incomplete [capaths] worked, that should not have. These may now break
authentication in some cross-realm configurations.
We can't test the key rollover support in the TGS in the x-realm
path using just Heimdal because the krb5_get_creds() path will try a
referral, which will produce a cross-realm TGT that has the
enc_part.kvno set. But we can test this for the plain TGT case.
NOTE: The test runs and succeeds, but the client seems to be getting
a new x-realm TGT after we set the kvno to 0 or remove the
kvno from the tickets. This means we're not really testing
the TGS paths! So this test is not yet ready.
