Subject: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt (fwd)

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 09 Feb 2006 19:57:57 -0500

(replies from Sam and myself forthcoming, in separate messages)

---------- Forwarded Message ----------
Date: Thursday, February 09, 2006 12:27:52 AM +0000
From: Elwyn Davies <[email-masked]>
To: [email-masked]
Subject: Gen art review of draft-ietf-cat-kerberos-pk-init-33.txt

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

---------- End Forwarded Message ----------