Re: [Ietf-krb-wg] Rechartering

[Thomas Hardjono <[e-mail]>]

Jeff, Larry, Tim,

I think the WG charter also needs to have language that express the
openness of the WG to the addition of well-defined new items (that are
not currently listed in the charter). It also need to define the
process to add such new items (beyond waiting for a recharter every
several years).

Otherwise we may have the situation where there are X number of items
progressing at glacial speed (because of one reason or another) and
the WG not accepting new items because these X items are stuck. Such a
situation would not encourage newcomers with new ideas to the WG.

ps. The draft looks good - I'll send other comments separately.


Thanks.

/thomas/

______________________________


> -----Original Message-----
> From: [e-mail] [mailto:ietf-krb-wg-
> [e-mail]] On Behalf Of Jeffrey Hutzelman
> Sent: Wednesday, March 16, 2011 12:33 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Ietf-krb-wg] Rechartering
> 
> OK, folks.  Below is draft 00 of a proposed charter update for the
> Kerberos working group.  I think this covers nearly all of the
> proposals I'm aware of, with the exception of KX509, which is
missing
> from this draft only because I'm tired and haven't figured out how
to
> write it up.
> 
> A couple of notes...
> 
> - This covers only the "Description of Working Group" part of the
>   charter, which should be the only part needing group discussion.
>   Milestones will be by agreement between the chairs, authors, and
AD,
>   and the rest is formulaic.
> 
> - I believe we work most effectively with a set of reasonable
focused
>   tasks, rather than a broad unrestricted mandate.  Therefore, the
>   work items in this proposal tend to be fairly focused.  The major
>   exception is enctype work, because it has been clearly
demonstrated
>   that we need the flexibility to adopt or review work in this area
>   as needed and on an ongoing basis.
> 
> - Generally, I believe working groups should be chartered to solve
>   specific problems, rather than to work on specific documents.  I
>   also believe that charters should usually leave the working group
>   free to choose the most appropriate solution or to develop more
than
>   one solution when circumstances warrant.  Therefore, the work
items
>   in this proposal tend to focus on a problem without mandating any
>   particular solution, and except for the "Complete existing work"
>   item, do not name specific documents.
> 
> - Formally, charter updates do not require working group consensus;
>   rather, they are a matter for the IESG and the responsible AD.
>   However, in practice, a charter which is supported by a consensus
>   of the working group is likely to be adopted with little
difficulty,
>   especially if there is demonstrated support in the form of
volunteers
>   willing to contribute to, edit, and review documents.  Therefore,
I
>   intend to send this on only when I believe that such a consensus
and
>   support exists.
> 
> Please send any comments to me and/or to the list.
> 
> -- Jeff
> 
> Description of Working Group:
> 
> Kerberos over the years has been ported to virtually every operating
> system.  There are at least two open source versions, with numerous
> commercial versions based on these and other proprietary
> implementations.
> Kerberos evolution has continued in recent years, with the
development
> of new crypto and preauthentication frameworks, support for initial
> authentication using public keys, improved support for protecting
> clients' long-term keys during initial authentication, support for
> anonymous and partially-anonymous authentication, and numerous
> extensions developed in and out of the IETF.
> 
> However, wider deployment and advances in technology bring with them
> both new challenges and new opportunities, such as exploring support
> for new mechanisms for initial authentication, new cryptographic
> technologies, and better integration of Kerberos with other systems
for
> authentication, authorization, and identity management.
> In addition, several key features remain undefined.
> 
> The Kerberos Working Group will continue to improve the core
Kerberos
> specification, develop extensions to address new needs and
technologies
> related to the areas described above, and produce specifications for
> missing functionality.
> 
> 
> Specifically, the Working Group will:
> 
> * Complete existing work, including:
>    - DHCP Option               (draft-sakane-dhc-dhcpv6-kdc-option-
> 09.txt)
>    - KDC Data Model            (draft-ietf-krb-wg-kdc-model-08.txt)
>    - One-Time Passwords
(draft-ietf-krb-wg-otp-preauth-13.txt)
>    - IAKERB                    (draft-ietf-krb-wg-iakerb-02.txt)
>    - Single-DES Deprecation    (draft-lha-des-die-die-die-05.txt)
> 
>    - Hash agility for GSS-KRB5
(draft-ietf-krb-wg-gss-cb-hash-agility-
> 05.txt)
>    - Hash agility for PKINIT
(draft-ietf-krb-wg-pkinit-alg-agility-
> 04.txt)
>    - Referrals
(draft-ietf-krb-wg-kerberos-referrals-
> 11.txt)
>    - Set/Change Password
(draft-ietf-krb-wg-kerberos-set-passwd-
> 06.txt)
> 
> * Prepare and advance one or more standards-track specifications
which
>   update the Kerberos version 5 protocol in a backward-compatible
way
>   to support non-ASCII principal and realm names, salt strings, and
>   passwords, and localized error reporting.
> 
> * Prepare and advance one or more standards-track specifications
which
>   update the Kerberos version 5 protocol in a backward-compatible
way
>   to enable future protocol revisions and extensions.
> 
> * Prepare, review, and advance standards-track and informational
>   specifications defining use of new cryptographic algorithms in the
>   Kerberos protocol, on an ongoing basis.
> 
> * Prepare and advance one or more standards-track specifications
>   defining a generalized Principal Authorization Data (PAD)
structure
>   for conveying authorization-related information.
> 
> * Prepare and advance one or more standards-track specifications
>   which define mechanisms for establishing keys and configuration
>   information used during authentication between Kerberos realms.
> 
> * Prepare and advance a standards-track specification defining a
>   format for the transport of Kerberos credentials within other
>   protocols.
> 
> * Produce an LDAP schema for management of the KDC's database.
> 
> 
> _______________________________________________
> ietf-krb-wg mailing list
> [e-mail]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

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