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

Leif Johansson <leifj@mnt.se> Sat, 05 January 2013 14:54 UTC

Return-Path: <ietf-krb-wg-bounces@lists.anl.gov>
X-Original-To: ietfarch-krb-wg-archive@ietfa.amsl.com
Delivered-To: ietfarch-krb-wg-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871A021F8615 for <ietfarch-krb-wg-archive@ietfa.amsl.com>; Sat, 5 Jan 2013 06:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level:
X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5 tests=[AWL=2.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 NsYQv28-xMKg for <ietfarch-krb-wg-archive@ietfa.amsl.com>; Sat, 5 Jan 2013 06:54:46 -0800 (PST)
Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7626421F8613 for <krb-wg-archive@lists.ietf.org>; Sat, 5 Jan 2013 06:54:46 -0800 (PST)
Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id C633A67; Sat, 5 Jan 2013 08:54:45 -0600 (CST)
Received: from lists.anl.gov (katydid.it.anl.gov [146.137.96.32]) by mailhost.anl.gov (Postfix) with ESMTP id 6D10866; Sat, 5 Jan 2013 08:54:44 -0600 (CST)
Received: from katydid.it.anl.gov (localhost [127.0.0.1]) by lists.anl.gov (Postfix) with ESMTP id 3D13854C03F; Sat, 5 Jan 2013 08:54:44 -0600 (CST)
X-Original-To: ietf-krb-wg@lists.anl.gov
Delivered-To: ietf-krb-wg@lists.anl.gov
Received: from mailrelay.anl.gov (mailrelay.anl.gov [130.202.101.22]) by lists.anl.gov (Postfix) with ESMTP id 2074381122 for <ietf-krb-wg@lists.anl.gov>; Sat, 5 Jan 2013 08:54:42 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by localhost.it.anl.gov (Postfix) with ESMTP id 02BA77CC0B3; Sat, 5 Jan 2013 08:54:42 -0600 (CST)
Received: from mailrelay.anl.gov ([127.0.0.1]) by localhost (mailrelay.anl.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31476-07; Sat, 5 Jan 2013 08:54:41 -0600 (CST)
Received: from mailgateway.anl.gov (mailgateway.anl.gov [130.202.101.28]) by mailrelay.anl.gov (Postfix) with ESMTP id C707D7CC09C for <ietf-krb-wg@lists.anl.gov>; Sat, 5 Jan 2013 08:54:41 -0600 (CST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: At8BAJk96FDRVdcqjWdsb2JhbABFDr1JFg4BAQEBCQkLCRIGI4IeAQEBAQIBAQEBNzQLBQsLDgouJw0BBQEcBhMfh3IGBAiZNpsWBIx3gz1hA5t2iH0/g1g/
X-IronPort-AV: E=Sophos;i="4.84,415,1355119200"; d="scan'208";a="9183255"
Received: from mail-la0-f42.google.com ([209.85.215.42]) by mailgateway.anl.gov with ESMTP/TLS/RC4-SHA; 05 Jan 2013 08:54:41 -0600
Received: by mail-la0-f42.google.com with SMTP id fe20so11596111lab.1 for <ietf-krb-wg@lists.anl.gov>; Sat, 05 Jan 2013 06:54:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=PUeb1w+3s0JuO5C05ul/cVXo3nr2jJ1Ubl+E/VzmCGc=; b=NlsbDnsRfKCTK0rFBa/UCK3Ad0Vix53LWYMBQFab6euP6mApx1FNqibZERkY3dFVsD HvjaXpKEBXkGW1YFTFr9mEqhEQN8BoGR7HddrqLMO0QJsy4NvQ3itpPz+UvhOsNZHOM5 F9CkmPvUGiQhlwCHiXu6c9gWTtPszxO361uEepfeYFN4j/BJtymx307J6SbNhTlgdrjk Vwd9cFbGI9odJaOZrgfxs7LZq5ZyWH4Me6LLxY00EtYL+JpQXpZ5zgFnTPiWjpYwTmVl lsuT0zYenbi/7KxgUhHUU8jJPVtzoYdJ2qk2HR//zfuRIF9CaOCGO2MAo5xCKxVGwRbp RAmw==
X-Received: by 10.112.50.138 with SMTP id c10mr22621286lbo.104.1357397679029; Sat, 05 Jan 2013 06:54:39 -0800 (PST)
Received: from [192.168.1.116] (c-2ec318ed-74736162.cust.telenor.se. [46.195.24.237]) by mx.google.com with ESMTPS id sr6sm20506783lab.4.2013.01.05.06.54.36 (version=SSLv3 cipher=OTHER); Sat, 05 Jan 2013 06:54:38 -0800 (PST)
References: <50E6966D.9040704__49484.1541782536$1357289172$gmane$org@oracle.com> <87mwwp19io.fsf@latte.josefsson.org> <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1357326252.18192.188.camel@destiny.pc.cs.cmu.edu>
Message-Id: <FADF05F4-61DA-42ED-8C24-45124C931C26@mnt.se>
X-Mailer: iPad Mail (10A523)
From: Leif Johansson <leifj@mnt.se>
Date: Sat, 05 Jan 2013 15:54:33 +0100
To: Jeffrey Hutzelman <jhutz@cmu.edu>
X-Gm-Message-State: ALoCoQmHczKo95SQA/iNE2ycwYCDOkZrrXURGEPXiXTNItiMu3nD6UKdNY/IMrhM6scFwsuJh0YI
X-Virus-Scanned: Debian amavisd-new at frigga.it.anl.gov
Cc: "kitten@ietf.org" <kitten@ietf.org>, Simon Josefsson <simon@josefsson.org>, "ietf-krb-wg@lists.anl.gov" <ietf-krb-wg@lists.anl.gov>, "jhutz@cmu.edu" <jhutz@cmu.edu>
Subject: Re: [Ietf-krb-wg] [kitten] Kitten and Kerberos WG Merger - New Charter
X-BeenThere: ietf-krb-wg@lists.anl.gov
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "This is a list for the IETF Kerberos Working Group. {WORLDPUB, EXTERNAL}" <ietf-krb-wg.lists.anl.gov>
List-Unsubscribe: <https://lists.anl.gov/mailman/options/ietf-krb-wg>, <mailto:ietf-krb-wg-request@lists.anl.gov?subject=unsubscribe>
List-Archive: <https://lists.anl.gov/pipermail/ietf-krb-wg>
List-Post: <mailto:ietf-krb-wg@lists.anl.gov>
List-Help: <mailto:ietf-krb-wg-request@lists.anl.gov?subject=help>
List-Subscribe: <https://lists.anl.gov/mailman/listinfo/ietf-krb-wg>, <mailto:ietf-krb-wg-request@lists.anl.gov?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ietf-krb-wg-bounces@lists.anl.gov
Sender: ietf-krb-wg-bounces@lists.anl.gov

4 jan 2013 kl. 20:04 skrev Jeffrey Hutzelman <jhutz@cmu.edu>:

> On Fri, 2013-01-04 at 12:18 +0100, Simon Josefsson wrote:
> 
>>> 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.
> 
> 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...
> 
> 
>>> 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.
> 
> 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.

Agreed 
> 
> 
> 
>>> 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.
> 
> ... 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.
> 
> 
>>> 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?
> 
> 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.
> 
> 
> 
>> 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.
> 
> 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.
> 
> 
> 
>>> 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 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
> 
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg