Draft:  draft-ietf-cat-kerberos-pk-init-33.txt
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date:  Wednesday 2/8/2006 6:28 PM CST
IETF LC Date: 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