Subject: [Ietf-krb-wg] [Technical Errata Reported] RFC4556 (3157)

From: RFC Errata System <[email-masked]>
Date: Thu, 15 Mar 2012 14:04:59 -0700 (PDT)

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-masked]>

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-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Mar 2012 17:25:59 -0400

...

This was discussed briefly on the WG mailing list before Tom submitted
the erratum.  It provides information needed for interoperability, in
several ways:

- It clarifies the behavior expected of compliant implementations, by
  explicitly pointing out how to derive correct values for Q for the
  affected group, when previously implementors had to infer this.

- It points out a noncompliant but widely-deployed behavior, and offers
  advice on what compliant implementations can do to interoperate when
  this behavior is seen.

The submitted erratum does _not_ change the protocol; particularly, it
neither permits the noncompliant behavior nor requires compliant
implementations to accept that behavior or interoperate with peers
exhibiting that behavior.

>From a process standpoint, I believe this submission meets the IESG's
published criteria for acceptance of errata for IETF-stream documents.

On the basis of the previous discussion, I do not expect this submission
to be controversial.  I therefore propose we allow a week or so for any
objections, after which point we would request that the IESG approve the
submission at its earliest convenience.

-- Jeff, as krb-wg co-chair