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

From: Simon Josefsson <[email-masked]>
Date: Fri, 04 Jan 2013 12:18:39 +0100

Shawn Emery <[email-masked]> writes:

> Common Authentication Technology Next Generation (kitten)
> ---------------------------------------------------------
>
>  Charter
...

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

> In detail, both existing and new work items include:
>
> Existing Working Group Items
> ---------------------------
> SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth)

Good idea -- will review, could contribute.

> SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec)

Good idea -- will contribute & review.

> GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana)

No objection.

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

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

> GSS-API Related
> ---------------
> Provide new interfaces for credential management, which include the
>       following:
>        initializing credentials
>        iterating credentials
>        exporting/importing credentials

Good idea -- will review, could contribute.

> Negotiable replay cache avoidance

No objection.

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

> Specify an option for exporting partially-established security
>       contexts and possibly a utility function for exporting security
>       contexts in an encrypted form, as well as a corresponding utility
>       function to decrypt and import such security context tokens.

Good idea - may review.

> Specify one-time password / two-factor authentication needs for SASL
>       applications.  This could be achieved through an explicit new
>       GSS-API/SASL mechanism (e.g.,
>       http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if
>       the consensus is that due to usability reasons, it is preferable to do
>       OTP/2FA through an higher level protocol
>       (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explaining
>       the usability problem and provide pointers for implementers.

Good idea -- will contribute.

> Kerberos Related
> ----------------
> Prepare and advance one or more standards-track specifications which
>       update the Kerberos version 5 protocol to support non-ASCII principal
>       and realm names, salt strings, and passwords, and localized error
>       reporting.  Maximizing backward compatibility is strongly desired.

Localized error reporting: good idea -- will contribute.  The draft for
it has been ready for a long time.

Regarding the rest I would prefer to wait until other protocols have
deployed PRECIS to gain experience with it.  Given the experience with
SASLprep in SASL it was fortunate that we didn't go that route with
Kerberos.  I don't want Kerberos to end up in a similar situation only
replacing SASLprep with PRECIS.

> Prepare, review, and advance standards-track and informational
>       specifications defining new authorization data types for carrying
>       supplemental information about the client to which a Kerberos ticket
>       has been issued and/or restrictions on what the ticket can be used
>       for. To enhance this ongoing authorization data work, a container
>       format supporting the use cases of draft-ietf-krb-wg-pad may be
>       standardized.

Good idea.

> Prepare a standards-track protocol to solve the use cases addressed
>       by draft-hotz-kx509-01 including new support for digital signatures.

Good idea.

> Today Kerberos requires a replay cache to be used in AP exchanges in
>       almost all cases.  Replay caches are quite complex to implement
>       correctly, particularly in clustered systems. High-performance replay
>       caches are even more difficult to implement.  The WG will pursue
>       extensions to minimize the need for replay caching, optimize replay
>       caching, and/or elide the need for replay caching.

Good idea.

> Prepare, review, and advance standards-track and informational
>       specifications defining use of new cryptographic algorithms in the
>       Kerberos protocol using the RFC3961 framework, on an ongoing
>       basis.  

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.

> Prepare, review, and advance standards-track and informational
>       specifications of new pre-authentication types for the Kerberos
>       protocol, on an ongoing basis.

Good idea.

> Prepare, review, and advance standards track updates and extensions to RFC4121,
>       as needed and on an ongoing basis.

Good idea.

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

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 04 Jan 2013 14:04:12 -0500

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

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

> > Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions)

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

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

> bad, I belive the WG should be able to review any proposal with

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.

> 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

---

From: t.p. <[email-masked]>
Date: Sat, 5 Jan 2013 12:20:35 +0000

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

> > > Kerberos IANA Registry
(draft-ietf-kitten-kerberos-iana-registries)

---

From: Leif Johansson <[email-masked]>
Date: Sat, 5 Jan 2013 15:54:33 +0100

> work that may never happen.

Agreed 
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Howard Chu <[email-masked]>
Date: Sun, 06 Jan 2013 04:07:08 -0800

>> work that may never happen.

Excuse me? Work that may never happen?
http://tools.ietf.org/html/draft-chu-ldap-kdc-schema-00

This has been waiting around for 3 years waiting for the Model document to be 
finalized. Naturally the schema can't be finalized before the Model.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 06 Jan 2013 12:57:24 -0500

>finalized. Naturally the schema can't be finalized before the Model.

Wow; I totally forgot about that.  Sorry.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 06 Jan 2013 12:57:23 -0500

---

From: Leif Johansson <[email-masked]>
Date: Sun, 6 Jan 2013 21:37:38 +0100

6 jan 2013 kl. 13:07 skrev Howard Chu <[email-masked]>:

> This has been waiting around for 3 years waiting for the Model document to be finalized. Naturally the schema can't be finalized before the Model.
>> 

Forgot about that one, nice!

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 06 Jan 2013 22:26:02 +0100

> ... but will you work on any of these items?  Review them?

No, I was merely stating my thoughts on all items in the list.  "Good
idea" didn't fit, and "Bad idea" was a too strong choice for me: I just
don't care about those drafts.  I currently don't plan to spend any
cycles on them.

> Additionally, there is no mechanism for localization of error message

All of GSS-API is clunky, to say the least.  I'm not convinced this
particular clunkyness is that important, but like Alexey said, if
someone describe a better error reporting interface, I could change
opinion.  It has to be so much better that it covers the migration
pains, which is a challenge.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 06 Jan 2013 22:30:03 +0100

Howard Chu <[email-masked]> writes:

> This has been waiting around for 3 years waiting for the Model
> document to be finalized. Naturally the schema can't be finalized
> before the Model.

If the LDAP schema document was updated to match the model document, and
the LDAP schema implemented and deployed, that would inspire confidence
in the model document.  However, if that work hasn't happened in 3
years, it is unrealistic to hope for it to materialize.  So I would
support shipping the model document now, with the risk of having to
update it later when there is implementation experience.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 6 Jan 2013 17:24:15 +0000

Using Simon's email as a template for my reply:

> familiar with the history.

No strong opinion either way, in particular I don't see this text as harmful/confusing.

> Good idea -- will review, could contribute.

Will review.
> Good idea -- will contribute & review.

Will review.
>> GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana)

:-(. Well, happy to get this done, but need some nagging from WG chairs, etc.
> together with an instanciation of it, such as an LDAP schema.

+1 to both.

>  I based

Same here, although I admit I haven't read any of these docs.

> Good idea -- will review, could contribute.

Will review. Can somebody write a strawman?
>> Negotiable replay cache avoidance

No opinion (outside of my area of expertise).
> argue why this is important?

Agreed. Or at least I would like to see a strawman, so that I can say "wow, how can I program without this in the past" ;)
>>      function to decrypt and import such security context tokens.

+1
> Good idea -- will contribute.

+1.

There was a somewhat similar proposal about doing dual PKI authentication: of a user and of a device. Are people interested in working on that one?
> it has been ready for a long time.

Will review.

>>      format supporting the use cases of draft-ietf-krb-wg-pad may be

Will review.

>>      by draft-hotz-kx509-01 including new support for digital signatures.

No idea, need to read the draft first.

>>      as needed and on an ongoing basis.

Overall I see this as a very long list of things that could be done, for which I don't think we collectively have cycles. Instead of having 20 deliverables, most without drafts, how about we pick 5 (or maybe 10, if people insist) and drive them to completion quicker. Rechartering is cheap!
> setting an aggresive timeline.

I am Ok with motivational milestones. Agree that the above is optimistic though.