Document:   draft-ietf-cat-kerberos-pk-init-34.txt
Reviewer: Elwyn Davies [elwynd@googlemail.com]
Review Date:  Monday 2/13/2006 10:38 AM CST
IESG Telechat Date:  Thursday, 16 February 2006

Summary: This is an updated version of the review of version 33 which I did for IETF LC.

This document is almost ready for PS.

There are three matters which seem to need attention (I missed the LC end 
deadline so none of these got addressed in -34 although there was some discussion):
1) While doing the LC review I was somewhat confused about the registrations of 
'magic numbers' across the various Kerberos RFCs/drafts.  I would normally have 
expected that RFC4120 established a number of IANA registries for things such as 
the 'key usage' numbers and 'error numbers' but I have now had it explained that 
registration 'has been retained in the Working Group' probably until rfc1510ter 
is published.  I personally have some qualms about the integrity of this unusual 
practice, and I don't see a single public list of the registrations (although 
somebody clearly knows them all!). It appears that RFC4120 'pre-registered' some 
of the items needed for this draft (flagged with [pkinit] in RFC4120) but in the 
subsequent development of this draft additional items have become necessary. I 
think it should be made clear which additional items are new and which were 
already registered in RFC4120 just as would be the case if there were IANA 
considerations.

2) The key usage number that is cited in s3.2.3.2 is overloaded (see detailed 
comment below).  Discussion indicates that this does not result in a security 
problem (because it is used with a different key) but there needs to be some 
comment to explain that this has happened and why it isn't a problem.

3) Appendix C should mention Windows XP.  Discussion indicates that the 'next 
version' after Windows 2003 Server referred to is not in fact Windows XP as this 
naive reader assumed but something that might have an internal code name of 
Vista.  However, I think this actually makes it more important to clarify the 
position of the KDC in Windows XP Professional.  Windows XP Professional is not 
just a Kerberos client but can also act as a server if I understand correctly 
because Windows XP Professional can act as a Windows security domain controller 
in which role the KDC has to offer services even if the whole system is not a 
'server' in the sense that Windows 2003 Server edition implies.

Overall, 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.

Detailed Review:
================
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)
Discussion has confirmed that this is NOT the same usage as #6 in RFC4120 and
rfc1510ter draft and it should have had a new key usage number allocated. 
Unfortunately it is probably too late to do this on account of existing 
implementations.

s6: 'This document has no actions for IANA.':  This is apparently technically 
correct. However s3.1.2 defines new error codes and other items which need to be 
'registered' since they are not in RFC4120.  RFC4120 reserves a number of error 
codes for pkinit but doesn't give actual meaning, but additional ones have been 
defined here (#s 77-81).  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.

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, ...'. Something
definite needs to be said about the KDC that will be active when Windows XP 
Professional is used as a domain controller.

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