Re: [Ietf-krb-wg] Kitten and Kerberos WG Merger - New Charter

4 jan 2013 kl. 20:04 skrev Jeffrey Hutzelman <[email protected]>:

> On Fri, 2013-01-04 at 12:18 +0100, Simon Josefsson wrote:
> 
>>> This charter subsumes the Kerberos WG under the auspices of the kitten WG.
>>> Therefore the following charter text contains both kitten and Kerberos WG items.
>> 
>> I suggest to remove this paragraph.  I don't see significant value in
>> having that in the WG charter, and it seems confusing for anyone not
>> familiar with the history.
> 
> That was actually put in as a way of recording the history and giving
> people not familiar with it a way to find older Kerberos-related work.
> However, it was not the topic of a lot of wordsmithing, and I don't
> think anyone who contributed to this proposal is wedded to that
> language.  So, if someone wants to propose alternate text...
> 
> 
>>> KDC Model (draft-ietf-krb-wg-kdc-model)
>> 
>> Long overdue.  I have always preferred that this document shipped
>> together with an instanciation of it, such as an LDAP schema.  I based
>> my KDC backend database on an earlier version of this draft, but the
>> document has changed since then.  Without implementations it is
>> difficult to know whether there are flaws in the abstract model.
> 
> It's certainly not going to ship "together with" a schema.  While I've
> heard various people speak in favor of having an LDAP schema over the
> years, including at the last krb-wg rechartering, there doesn't seem to
> be enough interest in actually working on it for anything to happen.
> The model document is nearly done (in the hands of the IESG, except for
> revisions Leif recently posted to the list on which there have _still_
> been no comments).  It's not going to sit around and wait for additional
> work that may never happen.

Agreed 
> 
> 
> 
>>> PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility)
>>> Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries)
>>> Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb)
>>> Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions)
>> 
>> No objection.
> 
> ... but will you work on any of these items?  Review them?
> 
> IAKERB was basically done some time ago, but needs an editor to manage
> the document through the various review processes on the way to getting
> it published.  
> 
> Ticket Extensions is a mostly complete proposal which krb-wg adopted
> some years ago, and which has languished since due to lack of cycles.
> This document is at version -00, and will probably need a couple of
> editing cycles before it reaches WGLC; it would be nice to see someone
> step up to do that work.
> 
> 
>>> Define interfaces for better error message reporting.
>> 
>> I'd rather not spend time on that.  Do we have a problem statement to
>> argue why this is important?
> 
> The GSS-API's error reporting interfaces are somewhat clunky, to say the
> least.  It is certainly possible to get a complete set of error
> messages, but since there is no connection to a particular context, it
> is unnecessarily complex for the implementation to report contextualized
> errors, especially when multiple threads and/or mechanisms are involved.
> Additionally, there is no mechanism for localization of error message
> text.
> 
> 
> 
>> Good idea -- will review.
>> 
>>>      Cryptographic algorithms intended for standards track status must be of
>>>      good quality, have broad international support, and fill a definite need.
>> 
>> IMHO this sentence is weasel-wording to motivate arbitrary decisions to
>> match some people's crypto preferences.  The IETF already have policies
>> around crypto (for example RFC 1984) that are sufficient motivation to
>> turn down obviously bad proposals.  When a proposal is not obviously
>> bad, I belive the WG should be able to review any proposal with
>> non-judgemental eyes.
> 
> We had this discussion during krb-wg's last rechartering, and this
> wording is the result of that hard-won consensus.  It doesn't prevent
> the WG from reviewing any proposal and even taking on work to produce an
> informational document.
> 
> It does constrain what can end up on the standards track.  In practice,
> I don't think the constraint is overly onerous.  For example, what kept
> camellia from being published on the standards track was not this
> requirement, but the lack of consensus within the WG to recommend it.
> 
> 
> 
>>> Goals and Milestones
>>> --------------------
>>> 
>>> Jan 2013    draft-ietf-kitten-sasl-oauth to IESG
>>> Jan 2013    draft-ietf-krb-wg-kdc-model to IESG
>>> Feb 2013    draft-ietf-krb-wg-pkinit-alg-agility to IESG
>>> Feb 2013    draft-ietf-kitten-sasl-saml-ec to IESG
>>> Mar 2013    draft-ietf-krb-wg-iakerb to IESG
>>> Mar 2013    draft-ietf-kitten-gssapi-extensions-iana to IESG
>>> Apr 2013    draft-ietf-krb-wg-cammac to IESG
>>> Apr 2013    draft-ietf-kitten-kerberos-iana-registries to IESG
>>> May 2013    draft-ietf-krb-wg-pad to IESG
>>> May 2013    Adopt work on one or more items for GSS-API cred management
>>> Jun 2013    Adopt work on better error reporting in the GSS-API
>>> Jun 2013    Adopt work on exporting partially-established GSS-API contexts
>>> Jul 2013    draft-ietf-krb-wg-ticket-extensions to IESG
>>> Jul 2013    Adopt work on the GSS-API for replay cache avoidance
>> 
>> I believe the targets are unrealistically optimistic, however my
>> perception is that the only purpose for having dates in the milestones
>> is to enable IESG to put pressure on WG's to deliver.  So I support
>> setting an aggresive timeline.
> 
> I agree that some of these are pretty optimistic.  However, at least
> some of the early ones look OK.  For example, kdc-model, pkinit-agility,
> and iakerb should all already be done enough to make or beat those
> deadlines, so I have no objections to them.
> 
> I can't speak to the GSS/SASL documents with early milestones, except
> that I do not believe the SASL OAuth document is ready to go -- it has a
> serious problem with the mechanism lying about mutual authentication,
> which I raised last month and to which I so far have seen no response.
> 
> -- Jeff
> 
> _______________________________________________
> Kitten mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/kitten