PKINIT: Support of MODP group 2?

[Julien Rische]

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