Re: Kitten and Kerberos WG Merger - New Charter

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

On 4 Jan 2013, at 11:18, Simon Josefsson <[email protected]> wrote:

> Shawn Emery <[email protected]> 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.

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

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

Will review.
> 
>> SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec)
> 
> Good idea -- will contribute & review.

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

:-(. Well, happy to get this done, but need some nagging from WG chairs, etc.
> 
>> 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.

+1 to both.

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

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

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

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

No opinion (outside of my area of expertise).
> 
>> 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?

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" ;)
> 
>> 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.

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

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

Will review.

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

Will review.

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

No idea, need to read the draft first.

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

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!
> 
>> 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 am Ok with motivational milestones. Agree that the above is optimistic though.