Review of draft-ietf-krb-wg-pkinit-alg-agility-06

[Jeffrey Hutzelman]

Below is my review of the PKINIT hash agility document. I found no
technical issues with this document, but there are a few issues that
need to be resolved. As always, I'd prefer to get responses to
everything, but the first five items are blockers and must be resolved
before the document can progress. In the case of point 3, only the
first part (verifying assignments in non-IANA registries) is blocking;
I'll leave it to the authors to use their judgment in determining
whether any changes need to be made to the document.

I need someone to validate the ASN.1 module in Appendix A.

I would also like to hear from anyone who has implemented this
specification or is planning to do so, and particularly from anyone who
was able to verify the test vectors in section 7.

-- Jeff


1) This document updates RFC4556; it needs a header to that effect.

2) The document seems to lack a disclaimer for pre-RFC5378 work, but was
first submitted before 10 November 2008. Should you add the disclaimer?
(See the Legal Provisions document at http://trustee.ietf.org/license-info
for more information.)

3) This document assigns the following values, drawn from registries
not yet managed by IANA. Please confirm that these values have
actually been assigned and are correct:

- id-pkinit-kdc OID arc (id-pkinit 6)
- Error type KDC_ERR_NO_ACCEPTABLE_KDF (82)

It may be desirable to include a "Number Assignments" section describing
these assignments, as was done in referrals.

Also, this document uses some values which were previously reserved
for it in an IANA-managed registry. It may be useful to include an
IANA considerations section indicating this, so IANA knows to update
the registry to refer to the published RFC.

4) The following acronyms must be expanded on first use:
- KDC (section 1, last graf)
- CA (section 5, graf 1)

5) The following references are obsolete:
- RFC 1320 (Obsoleted by RFC 6150)
- RFC 3280 (Obsoleted by RFC 5280)
- RFC 3852 (Obsoleted by RFC 5652)
- RFC 4634 (Obsoleted by RFC 6234)

6) Are RFC3766 and RFC6194 really normative references for this document?

[Tom Yu]

Post by Jeffrey Hutzelman
3) This document assigns the following values, drawn from registries
not yet managed by IANA. Please confirm that these values have
- id-pkinit-kdc OID arc (id-pkinit 6)

There is no known conflict for this OID, but I had not recorded it
yet. The ASN.1 module in Appendix A defines neither this OID nor its
children. It possibly should, while also mentioning that they are
used as RFC 3280 AlgorithmIdentifier OIDs, and that they have no
associated parameters when used as such.

Post by Jeffrey Hutzelman
- Error type KDC_ERR_NO_ACCEPTABLE_KDF (82)

There is no known conflict for this error code, and I have recorded it
earlier. It does not appear in the ASN.1 module, but we have tended
not to use ASN.1 to define error code assignments (unlike for preauth
and typed-data numbers).

Additionally, I already recorded the following assignments:

TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111
TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112

though to be syntactically correct ASN.1, they should be:

td-cms-digest-algorithms INTEGER ::= 111
td-cert-digest-algorithms INTEGER ::= 112

They also do not appear in the ASN.1 module.

[Sam Hartman]

Tom> Additionally, I already recorded the following assignments:

Tom> TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111
Tom> TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112

You don't control that registry any more.
RFc 6113 turns typed data and preauth types over to IANA.
So, should we update IANA considerations here?

[Jeffrey Hutzelman]

Post by Sam Hartman
Tom> TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111
Tom> TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112
You don't control that registry any more.
RFc 6113 turns typed data and preauth types over to IANA.
So, should we update IANA considerations here?

Yes; I mentioned this in my review:

Also, this document uses some values which were previously reserved
for it in an IANA-managed registry. It may be useful to include an
IANA considerations section indicating this, so IANA knows to update
the registry to refer to the published RFC.

-- Jeff

[Margaret Wasserman]

Hi Jeff,

Thanks for the review. All of your comments look reasonable, and I will publish and updated document to address these issues as soon as possible.

Margaret

Post by Jeffrey Hutzelman
Below is my review of the PKINIT hash agility document. I found no
technical issues with this document, but there are a few issues that
need to be resolved. As always, I'd prefer to get responses to
everything, but the first five items are blockers and must be resolved
before the document can progress. In the case of point 3, only the
first part (verifying assignments in non-IANA registries) is blocking;
I'll leave it to the authors to use their judgment in determining
whether any changes need to be made to the document.
I need someone to validate the ASN.1 module in Appendix A.
I would also like to hear from anyone who has implemented this
specification or is planning to do so, and particularly from anyone who
was able to verify the test vectors in section 7.
-- Jeff
1) This document updates RFC4556; it needs a header to that effect.
2) The document seems to lack a disclaimer for pre-RFC5378 work, but was
first submitted before 10 November 2008. Should you add the disclaimer?
(See the Legal Provisions document at http://trustee.ietf.org/license-info
for more information.)
3) This document assigns the following values, drawn from registries
not yet managed by IANA. Please confirm that these values have
- id-pkinit-kdc OID arc (id-pkinit 6)
- Error type KDC_ERR_NO_ACCEPTABLE_KDF (82)
It may be desirable to include a "Number Assignments" section describing
these assignments, as was done in referrals.
Also, this document uses some values which were previously reserved
for it in an IANA-managed registry. It may be useful to include an
IANA considerations section indicating this, so IANA knows to update
the registry to refer to the published RFC.
- KDC (section 1, last graf)
- CA (section 5, graf 1)
- RFC 1320 (Obsoleted by RFC 6150)
- RFC 3280 (Obsoleted by RFC 5280)
- RFC 3852 (Obsoleted by RFC 5652)
- RFC 4634 (Obsoleted by RFC 6234)
6) Are RFC3766 and RFC6194 really normative references for this document?
_______________________________________________
ietf-krb-wg mailing list
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Sam Hartman]

Margaret> Hi Jeff,

Margaret> Thanks for the review. All of your comments look
Margaret> reasonable, and I will publish and updated document to
Margaret> address these issues as soon as possible.

I'm speaking as an individual here, although I'm related a conversation
Jeff and I had where Jeff was in a chair role.

For the record, I'd like to note that Jeff and I have had an offline
discussion and we'd prefer not to introduce a number assignments section
into pkinit-alg-agility.
We still believe an IANA considerations section for IANA-managed values
is required.
So, you should disregard that comment.

[Jeffrey Hutzelman]

Post by Jeffrey Hutzelman
I need someone to validate the ASN.1 module in Appendix A.
I would also like to hear from anyone who has implemented this
specification or is planning to do so, and particularly from anyone who
was able to verify the test vectors in section 7.

I never got any responses to these points.
Verification of the ASN.1 module is more or less a requirement for the
document to progress. The others are not essential but will aid me in
producing a useful writeup.

-- Jeff

[Greg Hudson]

Post by Jeffrey Hutzelman
I need someone to validate the ASN.1 module in Appendix A.

asn1c accepts it, with one proviso. For the sake of its output model,
asn1c insists that all type names be unique. The module in the draft
extends the AuthPack and DHRepInfo sequences, using the same names as in
RFC 4556. To get asn1c to accept the module, those types have to be
renamed.

I was hoping to verify that asn1c actually produces encodings consistent
with our implementation of the spec, but I ran into a weird
inconsistency with asn1c's encoding of PrincipalName (from RFC 4120) and
need to work through that.

Post by Jeffrey Hutzelman
I would also like to hear from anyone who has implemented this
specification or is planning to do so, and particularly from anyone who
was able to verify the test vectors in section 7.

I didn't write it personally, but we have an implementation of this spec
in MIT krb5. I'll need to follow up (hopefully today, maybe tomorrow)
on whether we can verify the test vectors.

[Greg Hudson]

Post by Jeffrey Hutzelman
I would also like to hear from anyone who has implemented this
specification or is planning to do so, and particularly from anyone who
was able to verify the test vectors in section 7.

I just reviewed our test cases, and yes, we are verifying all of the
test vectors for our implementation (the outputs in 7.2.2, 7.3.2, and
7.4.2).

[Jeffrey Hutzelman]

Post by Jeffrey Hutzelman
6) Are RFC3766 and RFC6194 really normative references for this document?

I never saw an answer to this, and the references in question are still
in the normative references section in -07.

Additionally, while I originally pointed out that RFC1320 (MD4) had been
obsoleted by RFC6150 (MD4 to historic), the latter document does not
actually contain a description of the algorithm. Given the context,
maybe a reference to the original document is more appropriate.


Finally, Tom pointed out that the ASN.1 module in Appendix A does not
contain definitions for id-pkinit-kdc nor for the two new TD types.

And of course, we have the error code conflict. :-(

-- Jeff