RFC Errata
Found 2 records.
Status: Reported (1)
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
Source of RFC: krb-wg (sec)
Errata ID: 3820
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nicolas Williams
Date Reported: 2013-12-05
Section 3.2.2 says:
The type of the otherName field is AnotherName. The type-id field
of the type AnotherName is id-pkinit-san:
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
It should say:
The type of the otherName field is AnotherName. The type-id field
of the type AnotherName is id-kerberos-san:
id-kerberos-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
Notes:
The certificate subject alternative name (SAN) type added by RFC4556 is and has been used more generically than its symbolic name denotes.
Note that there is no risk in using id-pkinit-san for non-PKINIT purposes as presence of that SAN is -naturally- insufficient by itself to cause an AS to issue a ticket to the client for the named principal. RFC4556 is quite clear on this point.
Therefore id-pkinit-san should have been named id-kerberos-san, and should be referred to as id-kerberos-san going forward. (If there was a registry of PKIX certificate extensions we would additionally ask IANA to updte it.)
There are a few other mentions of id-pkinit-san in RFC4556, all of which should read id-kerberos-san instead.
Status: Held for Document Update (1)
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
Source of RFC: krb-wg (sec)
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).