[Ietf-krb-wg] Publication Request: draft-josefsson-kerberos5-starttls-07.txt (fwd)

[Jeffrey Hutzelman <[e-mail]>]

------------ Forwarded Message ------------
Date: Tuesday, December 01, 2009 04:24:59 PM -0500
From: Jeffrey Hutzelman <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Publication Request: draft-josefsson-kerberos5-starttls-07.txt

This is a request to the IESG to approve publication of "Using Kerberos
V5 over the Transport Layer Security (TLS) protocol",
draft-josefsson-kerberos5-starttls-07.txt, as an Informational RFC.
This document is a product of the Kerberos Working Group.

(1.a)  Who is the Document Shepherd for this document?  Has the
       Document Shepherd personally reviewed this version of the
       document and, in particular, does he or she believe this
       version is ready for forwarding to the IESG for publication?

       >> The Document Shepherd for this document is Jeffrey Hutzelman,
       >> <[e-mail]>.  I have reviewed this document, and I believe
       >> it is ready for IETF-wide review and publication as a
       >> Proposed Standard.

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

       >> This document has received review both within the working group
       >> and from key experts outside the working group.  Any issues raised
       >> have been resolved.

(1.c)  Does the Document Shepherd have concerns that the document
       needs more review from a particular or broader perspective,
       e.g., security, operational complexity, someone familiar with
       AAA, internationalization or XML?

       >> This document defines the use of TLS to protect exchanges
       >> between a Kerberos client and Key Distribution Center (KDC).
       >> As such, it depends on the security properties of TLS in
       >> ways that may warrant further review from subject-matter
       >> experts.  To date, no such review has been solicited or
       >> received.
       >>
       >> In addition, as described below, there is an issue which may
       >> benefit from input from PKIX experts.

(1.d)  Does the Document Shepherd have any specific concerns or
       issues with this document that the Responsible Area Director
       and/or the IESG should be aware of?  For example, perhaps he
       or she is uncomfortable with certain parts of the document, or
       has concerns whether there really is a need for it.  In any
       event, if the WG has discussed those issues and has indicated
       that it still wishes to advance the document, detail those
       concerns here.  Has an IPR disclosure related to this document
       been filed?  If so, please include a reference to the
       disclosure and summarize the WG discussion and conclusion on
       this issue.

       >> This document allows for two methods for Kerberos clients to
       >> verify the certificate of a KDC: preshared certificates and
       >> RFC5280 path validation.  For the later case, a new type is
       >> defined for the otherName field, containing the name of the
       >> Kerberos realm for which the certificate subject acts as KDC;
       >> the presence of a name of this type is taken to mean that the
       >> certificate may be used with this protocol.  No extended key
       >> purpose is defined for this protocol.
       >>
       >> Several concerns about this approach have been raised by some
       >> working group participants, including myself.  Particularly,
       >> it would seem appropriate to reuse the method used by PKINIT
       >> (RFC4556), which identifies a realm's KDC's using a particular
       >> value in the KRB5PrincipalName type defined in that document
       >> (see section 3.2.4), rather than defining a new name type.
       >> More importantly, the failure to define an extended key purpose
       >> means it would be impossible to issue a certificate which
       >> restricted to use only with this protocol, or with this
       >> protocol in combination with some other specific set of
       >> protocols, such as PKINIT.
       >>
       >> PKINIT defines a key purpose for use in certificates issued
       >> to KDC's, and requires its presence except in certificates
       >> which are identified as belonging to KDC's by use of the
       >> KRB5PrincipalName type with an appropriate value.  However, it
       >> does not waive RFC5280's requirement that a certificate which
       >> contains the extendedKeyUsage extension be used only for the
       >> specific purposes identified there.  We believe this approach
       >> to also be appropriate for the present document.
       >>
       >> The working group was unable to reach a consensus on this
       >> question, but there was a strong consensus that it would be
       >> preferable to move forward with the document rather than delay
       >> indefinitely attempting to come to a resolution.  Therefore,
       >> it was agreed that the document be submitted in its present
       >> form, with this issue called out and described in the writeup,
       >> and that participants who felt strongly about this issue would
       >> have the opportunity to re-raise it during IETF Last Call.
       >>
       >> This consensus and agreement to move forward was supported by
       >> all of those who participated in discussion of this issue,
       >> including myself.  Therefore, I expect no appeals or similar
       >> problems as a result.  However, I feel that additional input
       >> from PKIX experts may be helpful, and I do expect this issue
       >> to be raised during IETF Last Call.
       >>
       >> No IPR disclosures related to this document have been filed.

(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 is solid consensus within the working group to publish
       >> this document.  It is worth noting that a partial overlap
       >> exists between the functionality of this document and of the
       >> FAST preauthentication mechanism described in section 6.4 of
       >> draft-ietf-krb-wg-preauth-framework-15.txt, which provides
       >> an encrypted tunnel to protect exchange of preauthentication
       >> data between a client and a KDC.  The intended status of the
       >> latter document is standards track, and there exists a rough
       >> consensus to require implementation of the FAST mechanism
       >> in Kerberos implementations which conform to the framework
       >> defined in that document.  Therefore, we are requesting the
       >> publication of the present document as an Informational RFC,
       >> and may request that it be upgraded to Proposed Standard at
       >> a later time.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
       discontent?  If so, please summarise the areas of conflict in
       separate email messages to the Responsible Area Director.  (It
       should be in a separate email because this questionnaire is
       entered into the ID Tracker.)

       >> There have been no threats of appeal or other expressions of
       >> of discontent as a result of publication of this document.
       >> There is some dismay at the length of time it has taken to
       >> progress this document, as both the author and working group
       >> believed the technical aspects of the document were ready
       >> well over a year ago.  Unfortunately, this document has been
       >> through multiple cycles of long silence followed by a new
       >> issue surfacing just as the chair was about to move forward
       >> on it.

(1.g)  Has the Document Shepherd personally verified that the
       document satisfies all ID nits?  (See
       http://www.ietf.org/ID-Checklist.html and
       http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
       not enough; this check needs to be thorough.  Has the document
       met all formal review criteria it needs to, such as the MIB
       Doctor, media type and URI type reviews?

       >> This document has been run through the idnits tool, and was
       >> reviewed manually for compliance with requirements not checked
       >> by the automatic tool.  No additional formal review criteria
       >> apply to this document.

(1.h)  Has the document split its references into normative and
       informative?  Are there normative references to documents that
       are not ready for advancement or are otherwise in an unclear
       state?  If such normative references exist, what is the
       strategy for their completion?  Are there normative references
       that are downward references, as described in [RFC3967]?  If
       so, list these downward references to support the Area
       Director in the Last Call procedure for them [RFC3967].

       >> References have been split appropriately.  All references
       >> are to published RFC's, and all normative references are
       >> to BCP or standards-track documents.

(1.i)  Has the Document Shepherd verified that the document IANA
       consideration section exists and is consistent with the body
       of the document?  If the document specifies protocol
       extensions, are reservations requested in appropriate IANA
       registries?  Are the IANA registries clearly identified?  If
       the document creates a new registry, does it define the
       proposed initial contents of the registry and an allocation
       procedure for future registrations?  Does it suggest a
       reasonable name for the new registry?  See [RFC2434].  If the
       document describes an Expert Review process has Shepherd
       conferred with the Responsible Area Director so that the IESG
       can appoint the needed Expert during the IESG Evaluation?

       >> The IANA considerations section correctly reflects the one
       >> action required of IANA, which is to assign a Kerberos TCP
       >> extension number.
       >>
       >> This document also requires the assignment of a Kerberos
       >> Preauthentication Data Type number; however, that registry
       >> is currently controlled by the Kerberos working group and
       >> an appropriate number will be assigned before the document
       >> is published.  We hope soon to begin preparing a document
       >> which will turn this and several other Kerberos registries
       >> over to IANA.

(1.j)  Has the Document Shepherd verified that sections of the
       document that are written in a formal language, such as XML
       code, BNF rules, MIB definitions, etc., validate correctly in
       an automated checker?

       >> No part of this document is written in a formal language
       >> requiring such verification.  It does contain an ASN.1
       >> sequence definition which appears normatively in RFC4120
       >> and is copied in this document for clarity.

(1.k)  The IESG approval announcement includes a Document
       Announcement Write-Up.  Please provide such a Document
       Announcement Write-Up?  Recent examples can be found in the
       "Action" announcements for approved documents.  The approval
       announcement contains the following sections:


Technical Summary


   This document specify how the Kerberos V5 protocol can be transported
   over the Transport Layer Security (TLS) protocol, to provide
   additional security features.


Working Group Summary

   This technical specification represents the consensus of the
   Kerberos Working Group.  However, the working group is also
   working on an alternate solution to an overlapping problem.  It
   is not yet clear whether either or both specifications will win
   in the marketplace or whether either will become mandatory in a
   future version of the base Kerberos specification.  However, we
   feel it is important to publish these specifications to gain
   implemention and deployment experience.  Therefore, we are
   requesting publication of this document as an Informational RFC,
   and may request that it be upgraded to Proposed Standard at a
   later time.


Document Quality

   At least one implementor has indicated an intention to support
   the extension described in this document.


Personnel

   The Document Shepherd for this document is Jeffrey Hutzelman.
   The responsible Area Director is Tim Polk.



---------- End Forwarded Message ----------


_______________________________________________
ietf-krb-wg mailing list
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg