Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
RFC 4556

IANA Comments:
As described in the IANA Considerations section, we understand this document to have NO IANA Actions.
There are some values within the document.  The IANA would like confirmation that these do NOT need to be registered.

[Ballot comment]
draft-ietf-cat-kerberos-pk-init-34 says:

All data structures carried in OCTET  STRINGs must be encoded according to the rules specified in
  corresponding specifications.

"Corresponding specification" isn't very clear here, as it isn't clear how it relates to the data structures
spec.  I think this example is clear:

PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                  -- Contains a CMS type ContentInfo encoded
                  -- according to [RFC3852].

For this, the OCTET STRING is, in fact, encoded according to RFC3852 (CMS).
There are other data structures referring to other documents (e.g. 3280), but
this wasn't very clear from the original phrasing.  Would this be clearer?

Each data structure using OCTET STRINGs will provide a specific reference to the encoding
it uses.

[Ballot comment]
draft-ietf-cat-kerberos-pk-init-34 says:

All data structures carried in OCTET  STRINGs must be encoded according to the rules specified in
  corresponding specifications.

"Corresponding specification" isn't very clear here, as it isn't clear how it relates to the data structures
spec.  I think this example is clear:

PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                  -- Contains a CMS type ContentInfo encoded
                  -- according to [RFC3852].

For this, the OCTET STRING is, in fact, encoded according to RFC3852 (CMS).
There are other data structures referring to other documents (e.g. 3280), but
this wasn't very clear from the original phrasing.  Would this be clearer?

Each data Structures using OCTET STRINGs will provide a specific reference to the encoding
it uses.

[Ballot comment]
Logging the major comments from Gen-ART review by Elwyn Davies, on the pk-init draft:

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.

[Ballot discuss]
Genart review comments indicate that this spec re-uses key usage 6 for
a different purpose than RFC 4120.  From a security standpoint that
turns out to be fine.  However text explaining the re-use and noting
that it is not a security problem is required.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

    >> Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

    >> This document has been the primary work item of the Kerberos
    >> WG for some time, and has received extensive review from its
    >> participants.  It also has received review from a number of
    >> individuals not normally active in this WG.
    >>
    >> While we would welcome further review with respect to PKI
    >> issues, which are outside the core competence of this working
    >> group, I believe at this point that the document has received
    >> sufficient review in that area that I feel comfortable sending
    >> the document to the IESG.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

    >> No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

    >> No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

    >> This document represents a joint effort by a large number of
    >> working group participants, and I feel it represents the
    >> consensus of the group as a whole.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

    >> No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

    >> The automatic id-nits processor reports one line above 72
    >> characters; this can and should be fixed in editing.
    >>
    >> This document defines new types of Kerberos preauthentication
    >> data, authorization data, and typed-data, as well as several
    >> new Kerberos error codes.  As described in RFC4120, those
    >> registries are currently maintained by this WG, pending
    >> completion of an update to the Kerberos specification.  Thus,
    >> no IANA action is required for these codes.  In addition,
    >> several new Kerberos encryption types codes are reserved to
    >> have special meaning with PKINIT.  These codes were previously
    >> reserved in RFC3961 for use by PKINIT; thus, no new IANA
    >> actions are required.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

    >> Yes, normative and informative references are split.  All
    >> normative references are to published RFC's or IEEE or ITU-T
    >> specifications.
    >>
    >> There appear to be a few spurious references to RFC4121 where
    >> references to RFC4120 are all that is required, and there is a
    >> journal article listed in the informative references section
    >> which is not referenced in the text.  Presumably these issues
    >> can be fixed in editing.


Technical Summary

  This document describes protocol extensions (hereafter called PKINIT)
  to the Kerberos protocol specification.  These extensions provide a
  method for integrating public key cryptography into the initial
  authentication exchange, by using asymmetric-key signature and/or
  encryption algorithms in pre-authentication data fields.


Working Group Summary

  This document is the result of work begun nearly 10 years ago in
  the CAT working group.  In that time the two working groups have
  focused much of their energy on this work, resulting in quite a lot
  of discussion, some heated debate, and a few compromises.  Due to
  timing constraints, one significant stakeholder was forced to adopt
  and deploy an early version of this specification, rather than
  waiting for the final product.  While we regret being unable to
  meet their timeline, much of the intervening time was well-spent,
  and we think the protocol is significantly improved as a result.

  This document represents the consensus of the Kerberos Working Group.


Protocol Quality

  Several major Kerberos implementors have indicated an intent to
  implement this protocol; some have done so already.  While the
  current version has not yet been widely deployed, significant
  experience has been gained by wide deployment of earlier versions
  of this protocol.  This protocol was reviewed by Jeffrey Hutzelman.