[kitten] Finding Kerberos Realm Descriptors in secure DNS

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

Return-Path: <rick@openfortress.nl>
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 E25341B43E5 for <kitten@ietfa.amsl.com>; Mon, 14 Sep 2015 01:36:05 -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_20=-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 IYDpkLCleRIs for <kitten@ietfa.amsl.com>; Mon, 14 Sep 2015 01:36:03 -0700 (PDT)
Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE681B4627 for <kitten@ietf.org>; Mon, 14 Sep 2015 01:36:02 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id Gwbw1r00510HQrX01wbxrb; Mon, 14 Sep 2015 10:35:57 +0200
Message-ID: <55F686EA.30206@openfortress.nl>
Date: Mon, 14 Sep 2015 10:35:54 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/wcIyhaV7WHUcnU-NVdWj27MsIkc>
Subject: [kitten] Finding Kerberos Realm Descriptors in secure DNS
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: <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: Mon, 14 Sep 2015 08:36:06 -0000

Hello,

On DNSEXT, I’m discussing a new DNS record named “KREALM”, proposed here
before, to resolve things in secure DNS that the Kerberos specs didn’t
trust to put into DNS in the past. The thread can be found at
http://www.ietf.org/mail-archive/web/dnsext/current/threads.html#13822
and the I-D itself is located at
https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1

Where SRV records to kerberos’ own services are secure because they rely
on sharing a secret, and the mapping of DNS-style realm names to
case-insensitive DNS names has been standardised (ignore case, don’t
define two realms that only differ in case), there is no good option yet
to come from a DNS name to a realm name; not form a realm's DNS name
back to the realm name and not from a service's hostname to a realm
name. This is what KREALM tries to establish, using DNSSEC to provide
authenticity.

Think of service descriptions to find the realm for
HTTP/www.example.com, like

_http.www.example.com. IN KREALM “realm” “EXAMPLE.COM”
_http.www.example.com. IN KREALM "service" "HTTP"

(when not found, searches move upward in the DNS tree but not beyond the
zone apex; the I-D specifies an efficient, DNS-folk-agreeable way of
doing this)

but also think of realm descriptive information like

example.com. IN KREALM "realm" "EXAMPLE.COM"
example.com. IN KREALM "admin" "john/admin@EXAMPLE.COM"
example.com. IN KREALM "admin.uri" "http://www.example.com/contact.html"
example.com. IN KREALM "admin.uri"
"ldap://ldap.example.com/?cn=John+Smith,dc=example,dc=com"
example.com. IN KREALM "admin.cert" "admcert.example.com."
admcert.example.com. IN CERT ...

Now, the question surfaces what use cases of KREALM records could exist.
I’ve identified three or four:

 1.

    Kerberos client (or his KDC) knows service name + hostname, and
    wants to find a realm name

 2.

    Kerberos node wants to find the case-sensitive realm name for a DNS
    name, in a secure manner

 3. Kerberos node wants to find automatic validation information for a
    realm administrator (principal name)
 4. Kerberos node wants to find manual contact information for a realm
    administrator (perhaps through a URI and/or CERT record with an
    X.509 or PGP certificate)
 5. (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. I am aware that the keys will be vital for trust
in the information found!

If you have anything to add (or remove) then please let me know!
Everything will be setup to be extensible, and there should be non
reason why an admin would be forced to comply to a use case for their
services if they don’t want to, of course.

-Rick

​