I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Document: draft-ietf-cat-kerberos-pk-init-33.txt
Intended Status: Proposed Standard ((Long Defunct) WG submission)
Shepherding AD: Sam Hartman
Proto Shepherd: [EMAIL PROTECTED]
Review Trigger: IETF Last Call (ends 8 Feb 2006)
Summary:
It must be the week for old drafts to finally come in from the cold (see
Scott Brim's comments on draft-ietf-pwe3-fragmentation-10.txt)! I think
this one must hold some sort of record for long gestation: the -00
version seems to have disappeared from the archives I can get at but the
Internet Report for March 1995 documents its publication and it is
mentioned in a presentation from 13 March 1995. The -01 version was
published in June 1996, so it has been on the stocks for almost 11 years
and 34 versions!! Only draft-ietf-dnsext-mdns-45.txt has been through
more versions and that is a mere stripling at 5 years gestation.
Well, I fear I may be going to provoke another version, because although
it is IMO almost ready for PS, the IANA considerations need some
attention. I am also unsure if the key usage number that is cited in
s3.2.3.2 is right (see detailed comment below).
It would also be good to make Appendix C a little more up to the minute
if it is going to remain in place.
I have to say that this must also count as one of the most information
dense drafts I have encountered but I felt reasonably happy that it was
saying the right things. Disclaimer: I am assuming that the ASN.1 has
been automatically checked and I am not a security expert so I cannot
express an opinion on the correctness of the algorithms etc although I
noted that some detailed analysis had been carried out and bugs fixed as
a result. One item which should be carefully checked before final
publication: There are a number of OIDs embedded in comments in the
ASN.1 (e.g., the comments to the definition of PA-PK-AS-REQ in s3.2.1)
and these can only be checked manually. I don't have the information to
verify these items.
Issues:
s3.2.3.2: Key usage magic number 6. This number is presumably taken
from the list in RFC4120 but I can't tally the usage in this draft with
the specification in RFC4120
6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
keyed with the TGS session key (Section 5.5.1)
I suspect that this is NOT the same usage as #6 in RFC4120 and
rfc1510ter draft and it needs a new key usage number allocated.
I tried to find the registries apparently set up by RFC4120 but I
couldn't find them! Maybe I was looking in the wrong place as I did
find a message discussing the expert review for allocating some new key
usage numbers for KINK and there is also a list in
draft-ietf-krb-wg-rfc1510ter-02.txt.
s6: 'This document has no actions for IANA.': This is not correct. At
least s3.1.2 defines new error codes and other items which need to be
registered. RFC4120 reserves a number of error codes for pkinit but
doesn't give actual meaning, but additional ones have been defined here
(#s 77-80). The authorization data type is new and TD_DH_PARAMETERS is
new. Also RFC4120 reserves two unused pre-authentication data types for
pkinit (..._OLD - #s 14 and 15) - these should probably be noted as
deprecated. I am not sure about the items in s3.1.3. I also think the
key usage number needs registration (and a name?).
Appendix C: This talks mainly about Windows 2000 and states 'It is
anticipated that the next release of Windows is already too far along to
allow it to support the issuing KDC certificates with id-pkinit-san SAN
as specified in this RFC. Instead, ...'. I think this appendix is a
victim of the long gestation time of this draft. Maybe something
definite can be said about Windows XP if this is thought useful?
Very minor:
s3.2.3.1: Derivation of AS reply key, Step 3: '...K-truncate truncates
its input to the first K bits.' s/first/leftmost/ possibly.
Editorial:
s1, para 2: s/The corner-stone of Kerberos V5 is/The corner-stones of
Kerberos V5 are/
s1,bullets 1 and 2: the acronyms AS and TGS are slightly overloaded (S
stands for either Service or Server in both cases).
s8,para: s/In addition, if any CA is trusted to issue KDC certificates
can also/In addition, if any CA that is trusted to issue KDC
certificates can also
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
