RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Report New Errata



Advanced Search