Subject: RE: PKINIT-30 editorial changes

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 28 Nov 2005 04:15:44 -0800

3 errors for the hash algorithms are now added.

Section 3.2.2.

   If the digest algorithm used in generating the CA signature for the
   public key in any certificate of the request is not acceptable by the
   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message of the code
   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
   encoded in TYPED-DATA although none is defined at this point.

   If the client's public key is not accepted with reasons other than
   what were specified above, the KDC returns an error message with the
   code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no accompanying e-data
   currently defined for this error message.

<<< cut >>>

   If the digest algorithm used by the id-pkinit-authData is not
   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
   message of the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.  The
   accompanying e-data MUST be encoded in TYPED-DATA although none is
   defined at this point.

Section 3.2.3.1

   If the hash algorithm used in the key derivation function (currently
   only octetstring2key() is defined) is not acceptable by the KDC, the
   KDC MUST return a KRB-ERROR [RFC4120] message of the code
   KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED.  The accompanying e-data MUST be
   encoded in TYPED-DATA although none is defined at this point.

In addition, the following paragraph should really be in 3.2.3.2, not in
section 3.2.2.

   If there is a supportedCMSTypes field in the AuthPack, the KDC must
   check to see if it supports any of the listed types.  If it supports
   more than one of the types, the KDC SHOULD use the one listed first.
   If it does not support any of them, it MUST return an error message
   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].

-----Original Message-----
From: Liqiang(Larry) Zhu 
Sent: Monday, November 28, 2005 3:31 AM
To: [email-masked]'
Cc: 'Jeffrey Hutzelman'
Subject: PKINIT-30 editorial changes

Attached should contain all agreed-upon changes so far. I also tried to
write somewhat more detailed descriptions for each change.

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                     Microsoft Corporation
Expires: June 1, 2006                                            B. Tung
                                      USC Information Sciences Institute

[lzhu] this change would make sense, wouldn't it?

   In this document, an empty sequence in an optional field can be
   either included or omitted: both encodings are permitted and
   considered equivalent.

[lzhu] this is what we agreed in IETF64.

   In this document, the term "Modular Exponential Diffie-Hellman" is
   used to refer to the Diffie-Hellman key exchange as described in
   [RFC2631], in order to differentiate it from other equivalent
   representations of the same key agreement algorithm.

[lzhu] this was what confused Jeff about the references. Additional
changes were made to make the specific references clear to read. Such as

       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])

       Notes to CMS
       implementers: the signed attribute content-type MUST be present
       in this SignedData instance and its value is id-pkinit-authData
       according to [RFC3852].

[lzhu] added per request from Love, there are 2 other similar changes
but the same reason.

   The ExternalPrincipalIdentifier structure is used in this document to
   identify the subject's public key thereby the subject principal.
   This structure is filled out as follows:

   1.  The subjectName field contains a PKIX type Name encoded according
       to [RFC3280].  This field identifies the certificate subject by
       the distinguished subject name.  This field is REQUIRED when
       there is a distinguished subject name present in the certificate
       being used.

   2.  The issuerAndSerialNumber field contains a CMS type
       IssuerAndSerialNumber encoded according to [RFC3852].  This field
       identifies a certificate of the subject.  This field is REQUIRED
       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
       structures are defined in Section 3.2.2).

   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
       public key by a key identifier.  When an X.509 certificate is
       referenced, this key identifier matches the X.509
       subjectKeyIdentifier extension value.  When other certificate
       formats are referenced, the documents that specify the
       certificate format and their use with the CMS must include
       details on matching the key identifier to the appropriate
       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
       CERTIFIERS (as defined in Section 3.2.2).

[lzhu] added per request from Love.

How to fill in PKAuthenticator and part of AuthPack is currently missing
in the main body of the text, I can not argue it is not normative, but
the current description is rather clear. This is the part of comments I
found agreeable from jeff's email. In theory all I need to do is to copy
the comments to the main body for these fields, if this working group
feels strong about doing that, I can do that too.

   The AlgorithmIdentifier structure is defined in [RFC3280] and is
   filled in according to [RFC3279].  More specifically Section 2.3.3 of
   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
   in the case where MODP Diffie-Hellman key exchange is used.

[lzhu] requested by Love.

   Furthermore the KDC computes the checksum of the AS-REQ in the client
   request.  This checksum is performed over the type AS-REQ and the
   protocol key [RFC3961] of the checksum operation is the replyKey and
   the key usage number is 6.  If the replyKey's enctype is "newer"
   [RFC4120] [RFC4121], the checksum operation is the required checksum
   operation [RFC3961] of that enctype.

[lzhu] requested by love.

   When the Diffie-Hellman key exchange method is used, additional pre-
   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
   defined in this specification) is not bound to the AS_REQ by the
   mechanisms discussed in this specification (meaning it may be dropped
   from the request by attackers without being detected by either the
   client or the KDC).  Designers of additional pre-authentication data
   should take that into consideration if such additional pre-
   authentication data can be used in conjunction with the PA_PK_AS_REQ.
   The future work of the Kerberos working group is expected to update
   the hash algorithms specified in this document and provide a generic
   mechanism to bind additional pre-authentication data with the
   accompanying AS_REQ.

[lzhu] requested by Aaron and Love.