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-34.txt
Intended Status: Proposed Standard ((Defunct)WG submission)
Shepherding AD: Sam Hartman
Proto Shepherd: [EMAIL PROTECTED]
Review Trigger: IESG Telechat 16 Feb 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
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
