Re: [kitten] Kitten and Kerberos WG Merger - New Charter
Alexey Melnikov <alexey.melnikov@isode.com> Sun, 06 January 2013 17:19 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB621F8628 for <kitten@ietfa.amsl.com>; Sun, 6 Jan 2013 09:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level:
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeTj2hSRhFDY for <kitten@ietfa.amsl.com>; Sun, 6 Jan 2013 09:19:26 -0800 (PST)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7B221F8419 for <kitten@ietf.org>; Sun, 6 Jan 2013 09:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1357492763; d=isode.com; s=selector; i=@isode.com; bh=89xqdwhUrhpIhz/p97dqTCDN7oT2gqok0HgyKnBx+ow=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=w+OJ7joVNTATXzI5sTgIfcHyrzT3zNRM+V75gxNLHcagWFjvGbzJDHqCdU9MbZWOX82QzJ /beUn/9Fy93N8tt58ask6pJTYeRnYKoeG+/KpMj4qPLRG7hi8MrPC17nfR0GtGn9+QhHcM eFG/I+Vec/vU84AK9aND7JN6+4I6u0w=;
Received: from [92.41.44.166] (92.41.44.166.threembb.co.uk [92.41.44.166]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <UOmyGQBRrxj=@statler.isode.com>; Sun, 6 Jan 2013 17:19:23 +0000
References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org>
In-Reply-To: <87mwwp19io.fsf@latte.josefsson.org>
Message-Id: <A2D2FE53-815D-469B-8FDA-9F2C47EF48A8@isode.com>
X-Mailer: iPad Mail (9B206)
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Sun, 06 Jan 2013 17:24:15 +0000
To: Shawn Emery <shawn.emery@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" <kitten@ietf.org>, Simon Josefsson <simon@josefsson.org>, "ietf-krb-wg@lists.anl.gov" <ietf-krb-wg@lists.anl.gov>
Subject: Re: [kitten] Kitten and Kerberos WG Merger - New Charter
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Jan 2013 17:19:27 -0000
Using Simon's email as a template for my reply: On 4 Jan 2013, at 11:18, Simon Josefsson <simon@josefsson.org> wrote: > Shawn Emery <shawn.emery@oracle.com> 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.
- [kitten] Kitten and Kerberos WG Merger - New Char… Shawn Emery
- Re: [kitten] Kitten and Kerberos WG Merger - New … Simon Josefsson
- Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG… Jeffrey Hutzelman
- Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG… Leif Johansson
- Re: [kitten] Kitten and Kerberos WG Merger - New … Alexey Melnikov
- Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG… Jeffrey Hutzelman
- Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG… Jeffrey Hutzelman
- Re: [kitten] [Ietf-krb-wg] Kitten and Kerberos WG… Leif Johansson
- Re: [kitten] Kitten and Kerberos WG Merger - New … Simon Josefsson
- Re: [kitten] Kitten and Kerberos WG Merger - New … Simon Josefsson