Re: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt

Rick van Rein <rick@openfortress.nl> Mon, 14 September 2015 07:35 UTC

Return-Path: <rick@openfortress.nl>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D2E1A8932 for <dnsext@ietfa.amsl.com>; Mon, 14 Sep 2015 00:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 5A-ALK_A-XEN for <dnsext@ietfa.amsl.com>; Mon, 14 Sep 2015 00:35:04 -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 3B8C21B5FED for <dnsext@ietf.org>; Mon, 14 Sep 2015 00:35:03 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id Gvb01r00210HQrX01vb1NE; Mon, 14 Sep 2015 09:35:01 +0200
Message-ID: <55F678A2.6050101@openfortress.nl>
Date: Mon, 14 Sep 2015 09:34:58 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Niall O'Reilly <niall.oreilly@ucd.ie>, Tony Finch <dot@dotat.at>
References: <55E868E8.6050504@openfortress.nl> <alpine.LSU.2.00.1509081536450.734@hermes-2.csi.cam.ac.uk> <55F2A5CC.1080409@openfortress.nl> <alpine.LSU.2.00.1509111115410.29599@hermes-2.csi.cam.ac.uk> <55F2B555.4050105@openfortress.nl> <alpine.LSU.2.00.1509111207110.20720@hermes-2.csi.cam.ac.uk> <55F2B79A.3010701@openfortress.nl> <m2vbbh2hxg.wl-Niall.oReilly@ucd.ie>
In-Reply-To: <m2vbbh2hxg.wl-Niall.oReilly@ucd.ie>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/xKSZlmdjTnTXjLyGFdnpuL_Al3o>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2015 07:35:07 -0000

Hi all,

Clearly, I should take care of readable / writeable KREALM records,
rather than stuffing things in base64.  Very well...

1.
I propose to introduce a "groupname" in each KREALM, used to group
various records together like I wanted to do with KREALM records before.
Where I wrote
    KREALM "realm=A,realm=B,realm=C,service=S,service=T"
    KREALM "realm=D,service=S"
I was avoiding spelling out a cartesian product; the above was
describing the realm-service combinations
    A-S, B-S, C-S, A-T, B-T, C-T, D-S
An explicit group (arbitrary byte string that matches[*] to keep data
together like the RDATA above did) can be used as a first argument like in
    KREALM 1 realm A
    KREALM 1 realm B
    KREALM 1 realm C
    KREALM 1 service S
    KREALM 1 service T
    KREALM 2 realm D
    KREALM 2 service S
This enables the same compact notation to describe cartesian products,
it lets us define alternate groups of those to handle exceptions and as
a way to specify one-on-one definitions, and it fits into a fixed RDATA
form that can be read and written by DNS admins without base64 tools. 
It also exploits existing DNS structures to manage data lists.

[*] Don't know what "match" means yet.  We might go for something kinky
with wildcards, but that would complicate the data, complicate using it,
and interpret the byte sequence in a particular manner, so my current
gut feeling is to avoid being fancy and just use strcmp()

2.
There are three or four use cases that I see as valuable at this time:
2a. Kerberos client (or his KDC) knows service name + hostname, and
wants to find a realm name
2b. Kerberos node wants to find the case-sensitive realm name for a DNS
name, in a secure manner
2c. Kerberos node wants to find manual contact information for a realm
administrator (possibly "admin" pointers to a defining DNS node with RP,
CERT, ...)
2d / optional.  Kerberos client wants to perform service discovery under
a realm and/or at a DNS name
Based on these, I should be able to formulate the keys and search
patterns for the data.  It will probably also help me further
materialise the home record distinctive feature.

It will take me some time to collect my thoughts on this.  Also, I
intend to discuss it at the Kitten WG.

Thanks!
 -Rick