RFC 4556, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", June 2006

Note: This RFC has been updated by RFC 6112, RFC 8062, RFC 8636

Errata ID: 3157
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tom Yu
Date Reported: 2012-03-15
Held for Document Update by: Stephen Farrell

Section 3.2.1 says:

   8.  The client's Diffie-Hellman public value (clientPublicValue) is
       included if and only if the client wishes to use the Diffie-
       Hellman key agreement method.  The Diffie-Hellman domain
       parameters [IEEE1363] for the client's public key are specified
       in the algorithm field of the type SubjectPublicKeyInfo
       [RFC3279], and the client's Diffie-Hellman public key value is
       mapped to a subjectPublicKey (a BIT STRING) according to
       [RFC3279].  When using the Diffie-Hellman key agreement method,
       implementations MUST support Oakley 1024-bit Modular Exponential
       (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
       well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
       MODP well-known group 16 [RFC3526].

       The Diffie-Hellman field size should be chosen so as to provide
       sufficient cryptographic security [RFC3766].

       When MODP Diffie-Hellman is used, the exponents should have at
       least twice as many bits as the symmetric keys that will be
       derived from them [ODL99].

It should say:

   8.  The client's Diffie-Hellman public value (clientPublicValue) is
       included if and only if the client wishes to use the Diffie-
       Hellman key agreement method.  The Diffie-Hellman domain
       parameters [IEEE1363] for the client's public key are specified
       in the algorithm field of the type SubjectPublicKeyInfo
       [RFC3279], and the client's Diffie-Hellman public key value is
       mapped to a subjectPublicKey (a BIT STRING) according to
       [RFC3279].  When using the Diffie-Hellman key agreement method,
       implementations MUST support Oakley 1024-bit Modular Exponential
       (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
       well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
       MODP well-known group 16 [RFC3526].

       Some implementations are known to omit the mandatory Q value
       from the DomainParameters (in the algorithm value of the
       clientPublicValue) when using the well-known MODP groups 14 and
       16, which can cause an ASN.1 decoding error for the
       DomainParamters value.  While [RFC3526] does not explicitly
       specify the Q value for the well-known MODP groups 14 and 16,
       the prime modulus of each of these groups is a safe prime --
       having the form P = 2Q + 1, where P and Q are prime.
       Therefore, the Q value for each of these moduli is the
       corresponding Sophie Germain prime, and it is equal to (P-1)/2.

       The Diffie-Hellman field size should be chosen so as to provide
       sufficient cryptographic security [RFC3766].

       When MODP Diffie-Hellman is used, the exponents should have at
       least twice as many bits as the symmetric keys that will be
       derived from them [ODL99].

Notes:

The new paragraph identifies an interoperability problem where an
implementation omits the Q value (required in the DomainParameters
type defined in RFC3370) of a Diffie-Hellman group when participating
in PKINIT. This happens for two well-known IKEv2 MODP groups that are
defined in RFC3526, probably because RFC3526 does not explicitly state
the Q values for the moduli. The moduli are safe primes, so the new
text specifies how to compute their Q values (which are the
corresponding Sophie Germain primes).

Report New Errata