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

[Simon Josefsson <[e-mail]>]

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