The 'bits' parameter to select_dh_group() is the minimum acceptable
bit size. Rename 'bits' to 'min_bits' and fix the comparision
with krb5_dh_moduli.bits to ensure that DH groups whose bit size
is the minimum acceptable are not excluded.
Fixes#1002
Reported-By: Julien Rische (GitHub: jrisc)
Heimdal supports the 2 mandatory MODP groups (group 2 and group 14)
according to RFC4556, however group 14 is defined with a size of
1760 bits instead of 2048.
Fixes#1001
Reported-by: Julien Rische (GitHub: jrisc)
MSFT makes the `q` field of `DomainParameters` OPTIONAL even though it's
actually required. We currently validate DH groups not by validating
that p is a Sophie Germain prime but by checking the proposed group
against a compiled-in list and against a krb5.moduli file, therefore we
don't need q. Besides, for Oakley groups, because p is a Sophie Germain
prime, we'd have q=p/j and j=2, so we can always compute q as needed
(and MIT Kerberos does).
RFC8062 Section 7 requires verification of the PA-PKINIT-KX key excahnge
when anonymous PKINIT is used. Failure to do so can permit an active
attacker to become a man-in-the-middle.
Introduced by a1ef548600. First tagged
release Heimdal 1.4.0.
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N (4.8)
Change-Id: I6cc1c0c24985936468af08693839ac6c3edda133
Signed-off-by: Jeffrey Altman <jaltman@auristor.com>
Approved-by: Jeffrey Altman <jaltman@auritor.com>
Add macros to give symbolic names to the flags which can be passed to
krb5_get_init_creds_opt_set_pkinit(). Reserve flags for BTMM and not validating
KDC anchors.
On 32-bit Windows Intel builds the __cdecl and __stdcall calling
conventions are different so labeling the functions that are
exported or assigned to function pointers matters.
Change-Id: I03b6f34baeb9ffb2e683fd979f12f27a5078a4da
This adds a new backend for libhcrypto: the OpenSSL backend.
Now libhcrypto has these backends:
- hcrypto itself (i.e., the algorithms coded in lib/hcrypto)
- Common Crypto (OS X)
- PKCS#11 (specifically for Solaris, but not Solaris-specific)
- Windows CNG (Windows)
- OpenSSL (generic)
The ./configure --with-openssl=... option no longer disables the use of
hcrypto. Instead it enables the use of OpenSSL as a (and the default)
backend in libhcrypto. The libhcrypto framework is now always used.
OpenSSL should no longer be used directly within Heimdal, except in the
OpenSSL hcrypto backend itself, and files where elliptic curve (EC)
crypto is needed.
Because libhcrypto's EC support is incomplete, we can only use OpenSSL
for EC. Currently that means separating all EC-using code so that it
does not use hcrypto, thus the libhx509/hxtool and PKINIT EC code has
been moved out of the files it used to be in.
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
We turn on a few extra warnings and fix the fallout that occurs
when building with --enable-developer. Note that we get different
warnings on different machines and so this will be a work in
progress. So far, we have built on NetBSD/amd64 5.99.64 (which
uses gcc 4.5.3) and Ubuntu 10.04.3 LTS (which uses gcc 4.4.3).
Notably, we fixed
1. a lot of missing structure initialisers,
2. unchecked return values for functions that glibc
marks as __attribute__((warn-unused-result)),
3. made minor modifications to slc and asn1_compile
which can generate code which generates warnings,
and
4. a few stragglers here and there.
We turned off the extended warnings for many programs in appl/ as
they are nearing the end of their useful lifetime, e.g. rsh, rcp,
popper, ftp and telnet.
Interestingly, glibc's strncmp() macro needed to be worked around
whereas the function calls did not.
We have not yet tried this on 32 bit platforms, so there will be
a few more warnings when we do.
most of these warnings are not problems because of ample
use of abort() calls. However, the large number of warnings
makes it difficult to identify real problems. Initialize
the variables to shut up the compilers.
Change-Id: I8477c11b17c7b6a7d9074c721fdd2d7303b186a8
