Re: Kitten and Kerberos WG Merger - New Charter

----- Original Message -----
From: "Jeffrey Hutzelman" <[email protected]>
To: "Simon Josefsson" <[email protected]>
Cc: <[email protected]>; <[email protected]>; <[email protected]>
Sent: Friday, January 04, 2013 7:04 PM
> 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...

"This charter combines the work of the Kerberos WG and the
kitten WG (under the aegis of the kitten WG).  In places, it
identifies which WG was previously home for that work. "

I think that some text is required, for this and perhaps a
further update to the charter, should one occur in the
next year or two.

Tom Petch


> > > 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.
>
>
>
> > > 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
>
> _______________________________________________
> ietf-krb-wg mailing list
> [email protected]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
>


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