Subject: RE: PKINIT-30 editorial changes

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 29 Nov 2005 12:20:21 -0800

The initial text for how to construct PKAuthenticator is inconsistent
with RFC4120, therefore I would replace it with the following:

   5.  The AuthPack structure contains a PKAuthenticator, the client
       public key information, the CMS encryption types supported by the
       client and a DHNonce.  The pkAuthenticator field certifies to the
       KDC that the client has recent knowledge of the signing key that
       authenticates the client.  The clientPublicValue field specifies
       Diffie-Hellman domain parameters and the client's public key
       value.  The DH public key value is encoded as a BIT STRING
       according to [RFC3279].  The clientPublicValue field is present
       only if the client wishes to use the Diffie-Hellman key agreement
       method.  The supportedCMSTypes field specifies the list of CMS
       encryption types supported by the client in order of (decreasing)
       preference.  The clientDHNonce field is described later in this
       section.

   6.  The ctime field in the PKAuthenticator structure contains the
       current time on the client's host, and the cusec field contains
       the microsecond part of the client's timestamp.  The ctime and
       cusec fields are used together to specify a reasonably accurate
       timestamp [RFC4120].  The nonce field is chosen randomly.  The
       paChecksum field contains a SHA1 checksum that is performed over
       the KDC-REQ-BODY [RFC4120].

Any comments?

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Liqiang(Larry)
Zhu
Sent: Monday, November 28, 2005 10:42 AM
To: Jeffrey Altman
Cc: [email-masked]; Jeffrey Hutzelman
Subject: RE: PKINIT-30 editorial changes

Jeffrey Altman wrote:
> * the typographical errors in 3.2.3.1 were fixed

These were fixed because of previous comments from the list and/or
comments received before the WGLC for this document was concluded.

sha1WithRSAEncryption is now replaced with sha-1WithRSAEncryption. This
was a typo.

I can not be happier to copy the following comments into section 3.2.1.

   5.  The AuthPack structure contains a PKAuthenticator, the client
       public key information, the CMS encryption types supported by the
       client and a DHNonce.  The PKAuthenticator field certifies to the
       KDC that the client has recent knowledge of the signing key that
       authenticates the client (as described in more details later in
       this section).  The clientPublicValue field specifies Diffie-
       Hellman domain parameters and the client's public key value.  The
       DH public key value is encoded as a BIT STRING according to
       [RFC3279].  The clientPublicValue field is present only if the
       client wishes to use the Diffie-Hellman key agreement method.
       The supportedCMSTypes field specifies the list of CMS encryption
       types supported by the client in order of (decreasing)
       preference.  The clientDHNonce field is described later in this
       section.

   6.  The cusec and ctime fields in the PKAuthenticator structure have
       the same semantics as the corresponding cusec and ctime fields in
       the type Authenticator as defined in section 5.5.1 of [RFC4120].
       The nonce field is chosen randomly.  The paChecksum field
       contains a SHA1 checksum that is performed over the KDC-REQ-BODY
       [RFC4120].  Unless the KDC provides other suitable means to
       protect against replay, the KDC MUST utilize a replay cache to
       remember any PKAuthenticator presented within the allowable clock
       skew, in the same manner how the Authenticator structure is used
       to prevent replay in [RFC4120].

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Monday, November 28, 2005 7:59 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Jeffrey Hutzelman
Subject: Re: PKINIT-30 editorial changes

Larry:

Liqiang(Larry) Zhu wrote:

>    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

This does indeed clarify what is intended.

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

The identifier "id-aes256-CBC" is only referenced in the 3.1.3 list.  It

is not used anywhere else in the document.   Most importantly, the 
algorithm has not been assigned an encryption type value in Section 
3.1.2.  Is there a reason why 3.1.2 does not contain something similar
to:

        id-aes256-CBC-EnvOID                          XX
           -- Indicates that the client supports id-aes256-CBC

What is the relationship between the identifiers found here in 3.1.3 and

  the enctype value assignments in 3.1.2?  Assuming that 
"sha1WithRSAEncryption refers to "sha-1WithRSAEncryption" as listed in 
3.1.3, shouldn't the comment in 3.1.2 at the very least reference the 
3.1.3 identifier?

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

Making this change would make it much easier for someone trying to 
implement the draft as they would not have to bounce back and forth 
between different sections of the document in order to understand what 
must be done.

I still believe that adding "(see Section 3.2.1)" after 
"ExternalPrincipalIdentifier" in the ASN.1 comments of 
AD-INITIAL-VERIFIED-CAS would be helpful as well.  Another solution 
would be to duplicate the "ExternalPrincipalIdentifier" ASN.1 in Section

3.2.2.

----

In addition to the listed changes, I want to point out for the benefit 
of the group that you also addressed some other concerns I raised:

* the extraneous reference to X.509-97 that was not being used was
   removed

* the typographical errors in 3.2.3.1 were fixed

* the source of "dhpublicnumber" was corrected to reference RFC3279
   although without the reference to X9.42.  X9.42 is the original
   source of this identifier.

   [X9.42]   ANSI X9.42-2000, "Public Key Cryptography for The Financial
   Services Industry: Agreement of Symmetric Keys Using Discrete
   Logarithm Cryptography", December, 1999.

* the awkward text in 3.2.3.2 was fixed.

Thank you.

Jeffrey Altman

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 30 Nov 2005 01:23:41 -0500

>        the KDC-REQ-BODY [RFC4120].

This text reads very well.

Jeffrey Altman