# RFC Errata

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

Source of RFC: krb-wg (sec)
Errata ID: 3157

**Status: Held for Document Update
Type: Technical
**

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).