[Technical Errata Reported] RFC4556 (3157)

The following errata report has been submitted for RFC4556,
"Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4556&eid=3157

--------------------------------------
Type: Technical
Reported by: Tom Yu <[email protected]>

Section: 3.2.1

Original Text
-------------
   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].



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

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4556 (draft-ietf-cat-kerberos-pk-init-34)
--------------------------------------
Title               : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Publication Date    : June 2006
Author(s)           : L. Zhu, B. Tung
Category            : PROPOSED STANDARD
Source              : Kerberos WG
Area                : Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg