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
- [dnsext] New RRtype "KREALM" in draft-vanrein-dns… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Mark Andrews
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Tony Finch
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Tony Finch
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Tony Finch
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Niall O'Reilly
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Niall O'Reilly
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Patrik Fältström
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein