I'm ballotting no-objection on this draft and its
companion draft-ietf-krb-wg-ocsp-for-pkinit, since Sam
is holding a Discuss for the overloading of key number 6.
I wouldn't mind seeing Elwyn's other points fixed,
but please await Sam's direction.
Brian
Elwyn Davies wrote:
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
