PKINIT: Support of MODP group 2?

[Julien Rische]

Dear Heimdal developers,

The heimdal-team at heimdal.team address does not seem to work, so I'm forwarding
this email to your personal email addresses.


On Wed, Aug 17, 2022 at 5:19 PM Julien Rische <jrische at redhat.com> wrote:
>
> Dear fellow Kerberos developers,
>
> While working on a PKINIT interoperability issue[1] between Heimdal and MIT
> krb5, I realized OpenSSL was not supporting Diffie-Hellman MODP group 2[2][3].
>
> RFC4556[4] defines MODP groups 2 and 14[5] support as mandatory, while group
> 16[6] is optional. MIT krb5 supports the three of them and uses group 14 by
> default, while Heimdal supports the two mandatory groups (2 and 14), and uses
> group 2 by default.
>
> MS-PKCA[7] does not mention which groups are supported by Active Directory. I
> did some tests: group 14 works, but not group 16. It fails with MIT krb5 using
> group 2, but I am not sure if this failure means it is not supported by AD or
> if the error is coming from OpenSSL. I tried to test it with Heimdal, but I
> didn't manage to get the configuration right.
>
> I do not know when MODP group 2 support was dropped in OpenSSL. Actually I
> doubt it has ever been supported, since it is not part of the original set of
> supported well-known groups[8].
>
> I had some exchanges with OpenSSL developers about this issue, and I have some
> doubts they will accept to implement support for MODP group 2 as it is now
> considered outdated. I opened an OpenSSL feature request[9] too.
>
> Atop of that, there are ongoing plans to deprecate IKEv1 formally in an RFC:
>
>  "IKEv1 systems most likely do not support modern algorithms such as AES-GCM or
>   CHACHA20_POLY1305 and quite often only support or have been configured to use
>   the very weak DiffieHellman Groups 2 and 5."[10]
>
>  "[...] interoperability concerns mean that the defacto algorithms negotiated
>   by IKEv1 will consist of dated or deprecated algorithms like AES-CBC, SHA1,
>   and Diffie-Hellman groups 1 or 2."[11]
>
> In this context I am wondering if it is still relevant to keep MODP group 2 as
> MTI. Maybe we should write an RFC to make its support optional and deprecate
> it.
>
> If you agree with this point, and until such an RFC is accepted, I think in the
> MIT case we should also decide if efforts to restore support for MODP group 2
> would be justified. Either by pushing the OpenSSL development team to implement
> support for it, or by making our own implementation.
>
> Are you aware of some use cases having a strong dependency on group 2 that
> wouldn't be able to use group 14 instead?
>
> Regardless of the decision we make, I would like to ask the Heimdal development
> team if it would be okay to switch the default group to 14 instead of 2[12]. It
> would reduce the reliance on a group that is considered cryptographically weak,
> and simplify interoperability with MIT krb5.
>
> Please let us know about your opinion and any extra piece of information that
> would be relevant in that regard.
>
> --
> Julien Rische
> Software Engineer
> Red Hat
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2106296
> [2] https://datatracker.ietf.org/doc/html/rfc2412#appendix-E.2
> [3] https://datatracker.ietf.org/doc/html/rfc2409#section-6.2
> [4] https://datatracker.ietf.org/doc/html/rfc4556#page-13
> [5] https://datatracker.ietf.org/doc/html/rfc3526#section-3
> [6] https://datatracker.ietf.org/doc/html/rfc3526#section-5
> [7] https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-PKCA/[MS-PKCA]-211006.pdf
> [8] https://github.com/openssl/openssl/pull/4485/files#diff-7cee78cf63720ce0328619f0ac9753ab1f4db09cd13df459694225d0101ed857R2149-R2153
> [9] https://github.com/openssl/openssl/issues/18981
> [10] https://datatracker.ietf.org/doc/html/draft-pwouters-ikev1-ipsec-graveyard-00#section-3
> [11] https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev1-algo-to-historic#section-3
> [12] https://github.com/heimdal/heimdal/issues/1003