Notes from Review of PK-INIT-29

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Notes from Review of PK-INIT-29

Jeffrey Altman
The following is a list of notes produced during my review of PK-INIT-29:

-------------------
Section 3. Extensions second paragraph starts with:

"Briefly, this document defines the following extensions to [RFC4120]:"
and then goes on to describe an outline of the PK-INIT algorithm.  Are
these really separate extensions?  I believe the following is improved
text:

"Briefly, this document defines the PK-INIT extension to [RFC4120]
summarized below:"

-------------------

"Section 3.1.2. Defined Message and Encryption Types" provides a list of
encryption types (top of page 6).  Some of the names specified in the
comments appear to be incorrect as they do not correspond to the
algorithm identifiers described in Section 3.1.3.   Please make the
references consistent throughout the document.

  3.1.2 3.1.3
  dsaWithSHA1 id-dsa-with-sha1
  sha1WithRSAEncryption sha-1WithRSAEncryption
  rc2CBC rc2-cbc

In addition, in section 3.1.3 there is an algorithm identifier for
"id-aes256-CBC" for which there is not encryption type specified in 3.1.2.

-------------------

Section 3.1.3 contains the following:

"PKINIT uses the following algorithm identifer(s) for Diffie-Hellman key
agreement [RFC3279]:

"dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])"

I find these references confusing.  I can find no reference to "Modular
Exponential Diffie-Hellman" in RFC2631.  It is simply referred to as
"Diffie-Hellman Key Agreement Method".  The dhpublicnumber OID is
defined not in RFC2631 but in RFC3279 with reference to ANSI X9.42.

There are three references that belong here:

[RFC2631] "Diffie-Hellman Key Agreement Method"
[RFC3279] "Algorithms and Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile"
[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 following makes more sense to me:

"PKINIT uses the following algorithm identifer for Diffie-Hellman key
agreement [RFC2631]:

"dhpublicnumber [RFC2631][X9.42]"

with the additional [X9.42] reference added to the document.

As RFC3279 has already been updated with additional algorithms as per
RFC4055, I would also suggest that the additional references be listed as:

    sha-1WithRSAEncryption (RSA with SHA1)  [RFC3279]
    md5WithRSAEncryption   (RSA with MD5)   [RFC3279]
    id-dsa-with-sha1       (DSA with SHA1)  [RFC3279]

instead of indicating the reference to RFC3279 for all algorithm
identifiers in text

"PKINIT uses the following signature algorithm identifiers [RFC3279]:".
 Likewise with the other identifiers:

    rsaEncryption   (PKCS1 v2.1) [RFC3447]
    id-RSAES-OAEP (PKCS1 v2.1)    [RFC3447]


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

----------------------

Section 3.2.1 PA-PK-AS-REQ:

In the ASN.1 the first signedAuthPack comment reads "Contains a CMS type
ContentInfo encoded according to [RFC3852]" which due to the use of
"encoded" implies a normative requirement.   The explanatory text simply
reads "The ContentInfo [RFC3852] structure for the signedAuthPack field
is filled out as follows:" without indicating anything about the
encoding.  Either modify the comment to read "Contains a CMS type
ContentInfo [RFC3852]" or add a 0th requirement to the explanatory text
"0. ContentInfo structure is encoded according to [RFC3852]."

In the ASN.1 comments there is a habit of specifying numeric OID values
without their English tags or a reference to the external document from
which they were copied.  For example, in PA-PK-AS-REQ, "id-signedData
(1.2.840.113549.1.7.2)" which in the explanatory text on page 9 is
described as "id-signedDAata (as defined in [RFC3852])".

I believe this reference should be specified as "id-signedData {iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2} [RFC3852].
This should be done this way for two reasons.  First, by listing the
allocations it reduces the likelihood that the number will copied
incorrectly and not noticed.  Second, it should be clear that the
normative reference for this value is not PK-INIT but RFC3852.

Similar for the id-pkinit-authData OID.  Please provide the full tagged
OID and not just the numbers.

The information contained in the explanatory text labeled (4), (5), and
(6) are not referenced by the ASN.1 comments.   A reader of the ASN.1
would not know to look for the additional text.

The ASN.1 comments describing the rest of the ASN.1 fields for
PA-PK-AS-REQ, ExternalPrincipalIdentifier, AuthPack and PKAuthenticator
include implied normative text that is not included in the explanatory
text in section 3.2.1

ExternalPrincipalIdentifier subjectName specifies that this optional
field is REQUIRED when there is a distinguished subject name present in
the certificate.  This is not referenced anywhere else in the text.

ExternalPrincipalIdentitier is an ASN.1 type that is used in different
ways depending on which object type it is included.  For the purpose of
Section 3.2.1 which is intended to describe PA-PK-AS-REQ, the comments
for issuerAndSerialNumber and subjectKeyIdentifier should be focused on
when (if ever) those fields would be used in conjunction with
PA-PK-AS-REQ.  The current comments apply to other object types such as
TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS which are unrelated
to the construction of the PA-PK-AS-REQ.

It is my belief that if ASN.1 is going to be embedded in the text, the
purpose of the ASN.1 is meant to enhance the readability of the text.
As such, the comments associated with the data structures should be
focused on the topic currently being discussed.  An ASN.1 type such as
ExternalPrincipalIdentifier could be replicated in each of the sections
in which it is used with the appropriate subset of comments.   The ASN.1
module in the back of the document would contain a set of complete set
of comments including references to which section in the document the
comment refers to.

Given the lack of time available to edit this document and the desire
to publish immediately, I would suggest that all ASN.1 be removed from
the main body of the text and simply be replaced by references to the
objects in the ASN.1 module Appendix.   The comments in the ASN.1 should
be complete and should include references to the sections of the text
in which the object is referenced.

PA-PK-AS-REQ trustedCertifiers is an optional field marked SHOULD for
the KDC.  This normative reference does not appear elsewhere in the text.

PA-PK-AS-REQ trustedCertifiers and kdcPkId are both optional.  There is
no indication whether or not the client SHOULD or MAY send the data.

In 3.2.1 Note 7, should "...nonce string needs to be ..." be "...nonce
string MUST be ..."?

---------------------

Section 3.2.2:

Assuming the current layout of the document does not change, please add
"(see Section 3.2.1)" after "ExternalPrincipalIdentifier" in the ASN.1
comments of both TD-TRUSTED-CERTIFIERS and TD-INVALID-CERTIFIERS.

On page 12, there is the text:

"Even if the certification path is validated and the certificate is
mapped to the client's principal name, the KDC may decide not to accept
the client's certificate, depending on local policy."

Then on page 13, there is:

"As a matter of local policy, the KDC MAY decide to reject requests on
the basis of the absense or presence of other specific EKU OID's."

Followed by:

"If the client's public key is not accepted, the KDC returns an error
message with the code KDC_ERR_CLIENT_NOT_TRUSTED."

I suggest that the page 12 paragraph be merged into the page 13 paragraph.

"As a matter of local policy the KDC MAY choose for any reason to reject
an otherwise valid client certificate.  This may include the absence or
presence of specific EKU OIDs or anything else the policy maker
determines is relevant.

"If the client's public key is not accepted (regardless of whether or
not it came from a certificate), the KDC returns a KRB-ERROR with the
code KDC_ERR_CLIENT_NOT_TRUSTED."

-------------------------

Section 3.2.3:

Assuming the current layout of the document does not change, please add
"(see Section 3.2.1)" after "ExternalPrincipalIdentifier" in the ASN.1
comments of AD-INITIAL-VERIFIED-CAS.

The paragraph that begins "Application servers that understand this
authorization data type ...." should be moved to a new Section 3.2.5
that discusses the impact of PK-INIT on application servers.
Application server developers will not know to look within the
"Generation of KDC Reply" section for details that affect them.

In the PA-PK-AS-REP ASN.1, the comments for id-envelopedData, and
id-signedData should include the tagged OID value and the reference to
[RFC3852].

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

The reference to id-pkinit-rkeyData should include the tagged OID.

In the DHRepInfo ASN.1, the comments for id-signedData should contain
the tagged OID and a reference to RFC3852.  The id-pkinit-DHKeyData
comment should contain the tagged OID.

--------------------------

Section 3.2.3.1:

In note 5, remove the extraneous "." from "... field must only. be left ..."

--------------------------

Section 3.2.3.2:

There is no normative text other than the ReplyKeyPack ASN.1 describing
the use of "replyKey" and "asCheckSum".   The comments are descriptive
enough but should be replicated in the main body of the text describing
how to construct the PA-PK-AS-REP encKeyPack.

The last sentence in the section is awkward.  Change "... to support for
 RSA keys ..." to "... to support RSA keys ...".

--------------------------

Section 7.1:

The reference [X.509-97] is not used within the document and should be
removed from normative references.

--------------------------

Appendix A:

I have not validated that the ASN.1 module compiles.

--------------------------

Appendix C:

Please provide the tagged OID for all of the referenced SAN and EKU values.

--------------------------

Jeffrey Altman


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Notes from Review of PK-INIT-29

Sam Hartman-5
Speaking as an individual,  I'd like to object to the idea that the
ASN.1 would be removed from the text.  I think that the current
textual handling of ASN.1 is OK.


Speaking as an AD, this document is late.  The working group needs to
find an efficient means to publish this document.  Most of the issues
Jeff brought up seem to be editorial rather than blocking technical
comments.  Some of them, such as correct references for algorithms and
making sure algorithm names are correct are imporatnt to solve before
publication is requested.  However I hope that the wg does not spend
too much time resolving editorial issues.
Reply | Threaded
Open this post in threaded view
|

Re: Notes from Review of PK-INIT-29

Jeffrey Altman
In reply to this post by Jeffrey Altman
Jeffrey Altman wrote:
> The following is a list of notes produced during my review of PK-INIT-29:

I should clarify that these are my notes.  I believe it is crucial
that the handling of OIDs, proper attribution of references, the missing
enctype, the incorrect spelling of the algorithm identifiers, and the
gramatical corrections are changes the working group should endorse.

However, I do not believe that a significant re-write of the document
at this late date should be undertaken.  I do not know what should be
done about Section 3.2.1.  The text describing the construction of the
PA-PK-AS-REQ message is lacking in detail.  Unlike the other sections of
the document, the PA-PK-AS-REQ received much less attention.  The text
in the ASN.1 comments if extracted and merged with the existing notes
would most likely be sufficient if a note is added to the text stating
that the English descriptions are normative and the ASN.1 comments are
to be considered incomplete.

I would do the same for Section 3.2.3.2.

Jeffrey Altman



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Notes from Review of PK-INIT-29

Larry Zhu
In reply to this post by Jeffrey Altman
Notes from Review of PK-INIT-29
other those issues were already either agreed or rejected in IETF64 or in the past, and were already either fixed or dropped, that Jeff has included in his comments below, can anybody in the list read over Jeff's comments and offer a second opinion?
 
assuming all the comments in this email are all editorial, if there is no one in the list offering comments supporting the changes, the editor, that is yours truly, would have to drop the changes, if not all of these, based on his own discretion and on the ground of no consensus.
 
-- Larry
 


From: [hidden email] on behalf of Jeffrey Altman
Sent: Fri 11/25/2005 7:17 PM
To: Kerberos WG
Subject: Notes from Review of PK-INIT-29

The following is a list of notes produced during my review of PK-INIT-29:

-------------------
Section 3. Extensions second paragraph starts with:

"Briefly, this document defines the following extensions to [RFC4120]:"
and then goes on to describe an outline of the PK-INIT algorithm.  Are
these really separate extensions?  I believe the following is improved
text:

"Briefly, this document defines the PK-INIT extension to [RFC4120]
summarized below:"

-------------------

"Section 3.1.2. Defined Message and Encryption Types" provides a list of
encryption types (top of page 6).  Some of the names specified in the
comments appear to be incorrect as they do not correspond to the
algorithm identifiers described in Section 3.1.3.   Please make the
references consistent throughout the document.

  3.1.2                 3.1.3
  dsaWithSHA1           id-dsa-with-sha1
  sha1WithRSAEncryption sha-1WithRSAEncryption
  rc2CBC                rc2-cbc

In addition, in section 3.1.3 there is an algorithm identifier for
"id-aes256-CBC" for which there is not encryption type specified in 3.1.2.

-------------------

Section 3.1.3 contains the following:

"PKINIT uses the following algorithm identifer(s) for Diffie-Hellman key
agreement [RFC3279]:

"dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])"

I find these references confusing.  I can find no reference to "Modular
Exponential Diffie-Hellman" in RFC2631.  It is simply referred to as
"Diffie-Hellman Key Agreement Method".  The dhpublicnumber OID is
defined not in RFC2631 but in RFC3279 with reference to ANSI X9.42.

There are three references that belong here:

[RFC2631] "Diffie-Hellman Key Agreement Method"
[RFC3279] "Algorithms and Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile"
[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 following makes more sense to me:

"PKINIT uses the following algorithm identifer for Diffie-Hellman key
agreement [RFC2631]:

"dhpublicnumber [RFC2631][X9.42]"

with the additional [X9.42] reference added to the document.

As RFC3279 has already been updated with additional algorithms as per
RFC4055, I would also suggest that the additional references be listed as:

    sha-1WithRSAEncryption (RSA with SHA1)  [RFC3279]
    md5WithRSAEncryption   (RSA with MD5)   [RFC3279]
    id-dsa-with-sha1       (DSA with SHA1)  [RFC3279]

instead of indicating the reference to RFC3279 for all algorithm
identifiers in text

"PKINIT uses the following signature algorithm identifiers [RFC3279]:".
 Likewise with the other identifiers:

    rsaEncryption       (PKCS1 v2.1)    [RFC3447]
    id-RSAES-OAEP       (PKCS1 v2.1)    [RFC3447]


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

----------------------

Section 3.2.1 PA-PK-AS-REQ:

In the ASN.1 the first signedAuthPack comment reads "Contains a CMS type
ContentInfo encoded according to [RFC3852]" which due to the use of
"encoded" implies a normative requirement.   The explanatory text simply
reads "The ContentInfo [RFC3852] structure for the signedAuthPack field
is filled out as follows:" without indicating anything about the
encoding.  Either modify the comment to read "Contains a CMS type
ContentInfo [RFC3852]" or add a 0th requirement to the explanatory text
"0. ContentInfo structure is encoded according to [RFC3852]."

In the ASN.1 comments there is a habit of specifying numeric OID values
without their English tags or a reference to the external document from
which they were copied.  For example, in PA-PK-AS-REQ, "id-signedData
(1.2.840.113549.1.7.2)" which in the explanatory text on page 9 is
described as "id-signedDAata (as defined in [RFC3852])".

I believe this reference should be specified as "id-signedData {iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2} [RFC3852].
This should be done this way for two reasons.  First, by listing the
allocations it reduces the likelihood that the number will copied
incorrectly and not noticed.  Second, it should be clear that the
normative reference for this value is not PK-INIT but RFC3852.

Similar for the id-pkinit-authData OID.  Please provide the full tagged
OID and not just the numbers.

The information contained in the explanatory text labeled (4), (5), and
(6) are not referenced by the ASN.1 comments.   A reader of the ASN.1
would not know to look for the additional text.

The ASN.1 comments describing the rest of the ASN.1 fields for
PA-PK-AS-REQ, ExternalPrincipalIdentifier, AuthPack and PKAuthenticator
include implied normative text that is not included in the explanatory
text in section 3.2.1

ExternalPrincipalIdentifier subjectName specifies that this optional
field is REQUIRED when there is a distinguished subject name present in
the certificate.  This is not referenced anywhere else in the text.

ExternalPrincipalIdentitier is an ASN.1 type that is used in different
ways depending on which object type it is included.  For the purpose of
Section 3.2.1 which is intended to describe PA-PK-AS-REQ, the comments
for issuerAndSerialNumber and subjectKeyIdentifier should be focused on
when (if ever) those fields would be used in conjunction with
PA-PK-AS-REQ.  The current comments apply to other object types such as
TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS which are unrelated
to the construction of the PA-PK-AS-REQ.

It is my belief that if ASN.1 is going to be embedded in the text, the
purpose of the ASN.1 is meant to enhance the readability of the text.
As such, the comments associated with the data structures should be
focused on the topic currently being discussed.  An ASN.1 type such as
ExternalPrincipalIdentifier could be replicated in each of the sections
in which it is used with the appropriate subset of comments.   The ASN.1
module in the back of the document would contain a set of complete set
of comments including references to which section in the document the
comment refers to.

Given the lack of time available to edit this document and the desire
to publish immediately, I would suggest that all ASN.1 be removed from
the main body of the text and simply be replaced by references to the
objects in the ASN.1 module Appendix.   The comments in the ASN.1 should
be complete and should include references to the sections of the text
in which the object is referenced.

PA-PK-AS-REQ trustedCertifiers is an optional field marked SHOULD for
the KDC.  This normative reference does not appear elsewhere in the text.

PA-PK-AS-REQ trustedCertifiers and kdcPkId are both optional.  There is
no indication whether or not the client SHOULD or MAY send the data.

In 3.2.1 Note 7, should "...nonce string needs to be ..." be "...nonce
string MUST be ..."?

---------------------

Section 3.2.2:

Assuming the current layout of the document does not change, please add
"(see Section 3.2.1)" after "ExternalPrincipalIdentifier" in the ASN.1
comments of both TD-TRUSTED-CERTIFIERS and TD-INVALID-CERTIFIERS.

On page 12, there is the text:

"Even if the certification path is validated and the certificate is
mapped to the client's principal name, the KDC may decide not to accept
the client's certificate, depending on local policy."

Then on page 13, there is:

"As a matter of local policy, the KDC MAY decide to reject requests on
the basis of the absense or presence of other specific EKU OID's."

Followed by:

"If the client's public key is not accepted, the KDC returns an error
message with the code KDC_ERR_CLIENT_NOT_TRUSTED."

I suggest that the page 12 paragraph be merged into the page 13 paragraph.

"As a matter of local policy the KDC MAY choose for any reason to reject
an otherwise valid client certificate.  This may include the absence or
presence of specific EKU OIDs or anything else the policy maker
determines is relevant.

"If the client's public key is not accepted (regardless of whether or
not it came from a certificate), the KDC returns a KRB-ERROR with the
code KDC_ERR_CLIENT_NOT_TRUSTED."

-------------------------

Section 3.2.3:

Assuming the current layout of the document does not change, please add
"(see Section 3.2.1)" after "ExternalPrincipalIdentifier" in the ASN.1
comments of AD-INITIAL-VERIFIED-CAS.

The paragraph that begins "Application servers that understand this
authorization data type ...." should be moved to a new Section 3.2.5
that discusses the impact of PK-INIT on application servers.
Application server developers will not know to look within the
"Generation of KDC Reply" section for details that affect them.

In the PA-PK-AS-REP ASN.1, the comments for id-envelopedData, and
id-signedData should include the tagged OID value and the reference to
[RFC3852].

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

The reference to id-pkinit-rkeyData should include the tagged OID.

In the DHRepInfo ASN.1, the comments for id-signedData should contain
the tagged OID and a reference to RFC3852.  The id-pkinit-DHKeyData
comment should contain the tagged OID.

--------------------------

Section 3.2.3.1:

In note 5, remove the extraneous "." from "... field must only. be left ..."

--------------------------

Section 3.2.3.2:

There is no normative text other than the ReplyKeyPack ASN.1 describing
the use of "replyKey" and "asCheckSum".   The comments are descriptive
enough but should be replicated in the main body of the text describing
how to construct the PA-PK-AS-REP encKeyPack.

The last sentence in the section is awkward.  Change "... to support for
 RSA keys ..." to "... to support RSA keys ...".

--------------------------

Section 7.1:

The reference [X.509-97] is not used within the document and should be
removed from normative references.

--------------------------

Appendix A:

I have not validated that the ASN.1 module compiles.

--------------------------

Appendix C:

Please provide the tagged OID for all of the referenced SAN and EKU values.

--------------------------

Jeffrey Altman

Reply | Threaded
Open this post in threaded view
|

RE: Notes from Review of PK-INIT-29

Larry Zhu
In reply to this post by Sam Hartman-5
Re: Notes from Review of PK-INIT-29
sure. I will double check the accuracy of the references.


From: [hidden email] on behalf of Sam Hartman
Sent: Fri 11/25/2005 9:25 PM
To: Jeffrey Altman
Cc: Kerberos WG
Subject: Re: Notes from Review of PK-INIT-29

Speaking as an individual,  I'd like to object to the idea that the
ASN.1 would be removed from the text.  I think that the current
textual handling of ASN.1 is OK.


Speaking as an AD, this document is late.  The working group needs to
find an efficient means to publish this document.  Most of the issues
Jeff brought up seem to be editorial rather than blocking technical
comments.  Some of them, such as correct references for algorithms and
making sure algorithm names are correct are imporatnt to solve before
publication is requested.  However I hope that the wg does not spend
too much time resolving editorial issues.