Kerberos Cryptosystem Negotiation Extension
draft-zhu-kerb-enctype-nego-04

[Ballot comment]
KDC should be defined where first used (line 1 of the Introduction).

At the end of section 3:
  The server MAY ignore the preference order indicated by the client.
  The policy by which the client or the server chooses an enctype
  (i.e., how the preference order for the supported enctypes is
  selected) is a local matter.

Would it be useful to observe that this would actually allow
a local decision to prefer weaker security than chosen by the KDC?

  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?

    >> The document has been reviewed by key working group members.
    >> I don't feel there are any specific key individuals outside
    >> the working group whose review is essential at this stage.
    >> We do have significant overlap with groups whose work is
    >> most likely to be affected, such as KITTEN.

  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.)?

    >> Given the nature of the extension, I don't believe any
    >> particular broader review is required.  However, this
    >> extension adds new functionality to the Kerberos protocol
    >> which can be enjoyed only by Kerberos applications which
    >> make full use of sub-keys rather than mandating the direct
    >> use of Kerberos session keys.  As a result, some existing
    >> applications may not be able to take advantage of the new
    >> capability.  It is worth noting that applications which make
    >> use of authentication frameworks such as SASL or GSS-API
    >> _will_ be able to transparently use the new feature.

  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, I have no particular concerns about this document.

  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?

    >> There seems to be consensus behind this document among
    >> active participants in the working group.

  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 a new Kerberos authorization data type.
    >> As described in RFC4120, that registry is currently maintained
    >> by this WG, pending completion of an update to the Kerberos
    >> specifciation.  Thus, no IANA action is 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.)

    >> This document contains no non-normative references, aside
    >> from a spurious reference to RFC2743 (not used in the text)
    >> which should be removed.  All normative references are to
    >> published RFC's or ITU-T specifications.


Technical Summary

  This document specifies an extension to the Kerberos protocol where
  the client can send a list of supported encryption types in
  decreasing preference order, and the server then selects an
  encryption type that is supported by both the client and the server.


Working Group Summary

  This document represents the consensus of the Kerberos Working Group.


Protocol Quality

  At least one major implementor has already implemented this extension,
  and others have indicated their intent to do so.  This protocol was
  reviewed by Jeffrey Hutzelman.