Subject: [Ietf-krb-wg] RFC 4556 DH parameter oddities

From: Tom Yu <[email-masked]>
Date: Thu, 08 Mar 2012 19:28:29 -0500

RFC 4556 specifies the use of the 2048-bit and 4096-bit IKE ("OAKLEY")
MODP groups for Diffie-Hellman.  (numbers 14 and 16, respectively,
from RFC 3526) RFC 4556 also specifies the use of the DomainParameters
from Section 2.3.3 of RFC 3279.  The Q value is not optional in the
RFC 3279 DomainParameters ASN.1 type, but we have discovered that some
versions of Windows don't send the Q value when using IKE MODP group
14.

RFC 3526 doesn't list the Q value for the MODP primes, but some
analysis indicates that these primes are actually safe primes (of the
form P = 2Q + 1, and therefore satisfying P = 5 (mod 6)), so the Q
value can actually be computed by dividing P by 2.  (MIT's
implementation does this.)  This is not obvious (without having
certain number theory knowledge) from the text of RFC 3526, so it's
understandable that Windows would omit the Q value for the RFC 3526
primes.

How do we want to handle this?  For interop purposes, it should be
safe to accept domain parameters if they lack a Q value as long as P
matches one of the well-known safe primes.  This means altering
implementations to accept a missing Q value, which is otherwise
mandatory in the encoding.  We could bless the omission of Q in this
situation, or possibly clarify the correct Q value to send for these
primes.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Fri, 09 Mar 2012 13:17:49 -0500

On 03/08/2012 07:28 PM, Tom Yu wrote:
> matches one of the well-known safe primes.

If I understand correctly, I think what we want to do is:

* State the Q values for the affected groups, and reiterate that
implementations MUST send Q values when using those groups.

* Say that some implementations are known to use these groups without
sending Q values, and say that implementations MAY choose to accept
DomainParameters values with no Q value.

I don't think we'd want to more strongly require implementations to
accept Q-less DomainParameters values, since that could prohibit the use
of off-the-shelf CMS implementations.

>From a process perspective, I'm not sure how much of the above we can
say in an errata.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Mar 2012 13:23:44 -0500

> implementations MUST send Q values when using those groups.

We can certainly do this in an erratum.

> sending Q values

We can probably do this, too.

> , and say that implementations MAY choose to accept

This I'm less sure about.  It strays into modifying the protocol, but
it's a small modification that can only increase interoperability.  Of
course, there's also the question of whether we _want_ to do this.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Fri, 09 Mar 2012 14:53:23 -0500

Also, could someone with better number theory and/or cryptography
experience than me please confirm whether the RFC 3526 primes are
indeed safe primes?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg