[kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03

Rick van Rein <rick@openfortress.nl> Wed, 13 April 2016 08:32 UTC

Return-Path: <rick@openfortress.nl>
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 2601812D7BF for <kitten@ietfa.amsl.com>; Wed, 13 Apr 2016 01:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9RCkdvnDECR1 for <kitten@ietfa.amsl.com>; Wed, 13 Apr 2016 01:32:27 -0700 (PDT)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86DF12D68C for <kitten@ietf.org>; Wed, 13 Apr 2016 01:32:26 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id hkYN1s00M10HQrX01kYQfK; Wed, 13 Apr 2016 10:32:24 +0200
Message-ID: <570E0415.5090501@openfortress.nl>
Date: Wed, 13 Apr 2016 10:32:21 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Tom Yu <tlyu@MIT.EDU>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/75RfEjZ2UB7GhhNGvm7Hp7nzQEo>
X-Mailman-Approved-At: Wed, 13 Apr 2016 08:24:57 -0700
Cc: " <kitten@ietf.org>"
Subject: [kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Apr 2016 08:32:29 -0000

Hello Tom / Kitten,

Last week the Kerberos IANA registries draft popped up again.  I find
the general useful, but I feel strong objections against constraining
"Named Bit Assignments" to the 0..31 range.  I mentioned this before,
but now also see a way out.  My proposal is the replacement text at the
end of this email.

My reasons for my objection + alternative are

 (1) specifications should not follow implementations, and certainly not
confirm bad ones;
 (2) limiting to 32 named bits will confirm this lowest common
denominator and increase the number of flawed implementations;
 (3) after confirming a 32-bit limit, we have cut off any chance of
growing beyond this;
 (4) software that is incapable of being updated is a security problem,
not something that a spec should seek to confirm;
 (5) we currently cannot supply bits for experimental/private use, for
instance for development purposes; developers end up stealing bits and
the registry becomes an administration of such sins.

The suggestion below puts some suggestive pressure towards proper
implementation, by hinting at a future with bits beyond 32, also for
experimental/private use.  This is a hint in the direction that we would
like to have.  Also, it will help us grow an insight into which
implementations are flawed, which won't happen if we stuck to 32 bits.

Note that allowing more bits than anticipated is purely a parsing
matter; any implementation has a limited number of flags that it can
understand, and so the only requirement is to be able to parse DER
structures with more bits than understood; the default behaviour for
unknown flags can easily be triggered in any implementation by looking
at the extra bytes and responding to anything non-zero (which is easy
with DER, as the length will only be > (1+32/8) when a bit over 32 is
set).  After that potential trigger, only the understood (for instance,
32) bits need to be taken out for processing.  (For TicketFlags and
KDC-Options the unrecognised handling is even simpler, namely ignoring;
I could not find unrecognised handling for AP-Options but ignoring seems
to make sense there too.)

This leaves implementations of RFC 1510 which may be more restrictive. 
Assuming this problem is real, could we resolve it with policy settings
on supplied flags in client and/or KDC?


Cheers,
 -Rick


6.  Named bit assignments

   Names for named bit assignments must be unique within a given named
   bit registry, and typically do not have name prefixes that identify
   which registry they belong to.

   Assignments for named bits 0 through 31 require standards action,
   due to their scarcity; RFC 4120 predicts higher bit numbers, but use
   of these bits may involve fixing applications that falsely assume
   that no more than 32 named bits will ever be assigned.  These bits
   are available under a less restrictive policy because they are not
   scarce.


6.1.  AP-REQ options

   Registry name:      AP-REQ options

   Assignment policy:  Standards action
   Valid values:       ASN.1 bit numbers 0 through 31

   Assignment policy:  Experimental and Private Use
   Valid values:       ASN.1 bit numbers 32 through 35

   Assignment policy:  Specification Required
   Valid values:       ASN.1 bit numbers 36 and up
 
 
6.2.  KDC-REQ options

   Registry name:      KDC-REQ options

   Assignment policy:  Standards action
   Valid values:       ASN.1 bit numbers 0 through 31

   Assignment policy:  Experimental and Private Use
   Valid values:       ASN.1 bit numbers 32 through 35

   Assignment policy:  Specification Required
   Valid values:       ASN.1 bit numbers 36 and up


6.3.  Ticket flags

   Registry name:      Ticket flags

   Assignment policy:  Standards action
   Valid values:       ASN.1 bit numbers 0 through 31

   Assignment policy:  Experimental and Private Use
   Valid values:       ASN.1 bit numbers 32 through 35

   Assignment policy:  Specification Required
   Valid values:       ASN.1 bit numbers 36 and up