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

[Jeffrey Hutzelman <[e-mail]>]

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.



> > 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
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg