RFC 4556 DH parameter oddities
Tom Yu <[email protected]>
| Newsgroups | gmane.ietf.krb-wg |
|---|---|
| Message-ID | <[email protected]> |
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 protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg