Re: [kitten] Updating IANA krb5 GSSAPI token type registry

Sam Hartman <hartmans-ietf@mit.edu> Fri, 07 March 2014 15:12 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E821A01FC for <kitten@ietfa.amsl.com>; Fri, 7 Mar 2014 07:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tmJRCALMbEV for <kitten@ietfa.amsl.com>; Fri, 7 Mar 2014 07:12:27 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD691A0097 for <kitten@ietf.org>; Fri, 7 Mar 2014 07:12:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6D723206AC; Fri, 7 Mar 2014 10:07:50 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phlHcaibCV-O; Fri, 7 Mar 2014 10:07:50 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (unknown [217.41.226.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 7 Mar 2014 10:07:49 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0F17283F8D; Fri, 7 Mar 2014 10:12:20 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Benjamin Kaduk <kaduk@MIT.EDU>
References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <alpine.GSO.1.10.1308062018070.24720@multics.mit.edu> <alpine.GSO.1.10.1309041148130.16692@multics.mit.edu> <alpine.GSO.1.10.1403041135510.1213@multics.mit.edu> <tslzjl4ohbn.fsf@mit.edu> <1394031556.4290.53.camel@destiny.pc.cs.cmu.edu> <5317BD6E.6080309@oracle.com> <alpine.GSO.1.10.1403051916110.1213@multics.mit.edu> <tslpplzvdb0.fsf@mit.edu> <alpine.GSO.1.10.1403061729070.1213@multics.mit.edu>
Date: Fri, 07 Mar 2014 10:12:20 -0500
In-Reply-To: <alpine.GSO.1.10.1403061729070.1213@multics.mit.edu> (Benjamin Kaduk's message of "Thu, 6 Mar 2014 17:51:12 -0500 (EST)")
Message-ID: <tslob1idovf.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/27LKzs8wzgvkoAFbm7cqZMl_-y0
Cc: kitten@ietf.org, Sam Hartman <hartmans-ietf@MIT.EDU>
Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 07 Mar 2014 15:12:29 -0000

>>>>> "Benjamin" == Benjamin Kaduk <kaduk@MIT.EDU> writes:



    Benjamin> There actually is provision in RFC 2743 for tokens to be
    Benjamin> passed to gss_process_context_token which are not deletion
    Benjamin> tokens. (Last two paragraphs of 1.2.1.2.)  I do not
    Benjamin> remember any provisions in RFC 4121 to account for this
    Benjamin> case, though, so I guess it is under-specified.

Right, but no provisions to create such tokens.
If we start thinking about that, making sure  that RFC 4121 doesn't use
the token type used by CFX would be potentially desirable..

    >> In general, when you ship a draft, you take on responsibility for
    >> dealing if the IETF process doesn't go the way you anticipate.
    >> Doing that is part of doing business; it's definitely the case
    >> that there are times when you end up shipping based on drafts.

    Benjamin> I don't disagree with anything you say there.

    Benjamin> However, I think we should consider what the purpose of
    Benjamin> the central registry is: to document what values are in
    Benjamin> use and avoid conflicts. Given that there were already
    Benjamin> values in broad use when the registry was created, I think
    Benjamin> it is appropriate to document those values in the
    Benjamin> registry, even if it is just as "reserved to avoid
    Benjamin> conflicts", as Martin notes in the prior art.  There
    Benjamin> certainly does not seem to be a shortage of values in the
    Benjamin> token type space.

    >> IANA expert decisions can be appealed; you'd first file an appeal
    >> with me, and then I'm not sure whether it goes to the IESG as a
    >> whole or the security AD.

    Benjamin> Is there a magic phrase that invokes such an appeal?  (Or
    Benjamin> does it go through IANA?)  I am unfamiliar with the
    Benjamin> process, and not necessarily indicating intent to do so.


I'm not sure if there are more formal ways, but just drop me a note if
you decide it's important enough to appeal and say that.  INcluding
rationale would be good.