IETF Logo Mail Archive

Re: [kitten] Finding Kerberos Realm Descriptors in secure DNS

Rick van Rein <rick@openfortress.nl> Mon, 14 September 2015 15:58 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 0D9CE1B3A99 for <kitten@ietfa.amsl.com>; Mon, 14 Sep 2015 08:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3dEIYDL2x_gj for <kitten@ietfa.amsl.com>; Mon, 14 Sep 2015 08:58:07 -0700 (PDT)
Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79F91AC40E for <kitten@ietf.org>; Mon, 14 Sep 2015 08:58:06 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id H3y41r00A10HQrX013y5y2; Mon, 14 Sep 2015 17:58:05 +0200
Message-ID: <55F6EE8B.1020804@openfortress.nl>
Date: Mon, 14 Sep 2015 17:58:03 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
References: <55F686EA.30206@openfortress.nl> <55F6EA7C.8070608@mit.edu>
In-Reply-To: <55F6EA7C.8070608@mit.edu>
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/kitten/paJ9Z4ZDeksbuOEmYDgZn1uB9Yw>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [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 15:58:09 -0000

Hi Greg,

> I would advise reducing the problem statement.  We know we have a
> problem with hostname-to-realmname mappings; none of the other use cases
> strike me as real problems.  If we reduce the problem to "I have a
> hostname and I want the realm," then most of the complexity goes away.
I agree that the spec would get much simpler; I'm now trying to solve multiple things in one stroke and that might be going over the top.

When we step back to 1 or 2 use cases, we might still consider to use to KREALM construct that I'm now working on and that could support the more luxureous features in the feature, how does that idea strike you if the actual resolution got really straightforward for the defined use cases?  I mean, if we limit the number of use cases supported that doesn't necessarily mean that we should also define the least extensible KREALM RR around it?

-Rick

v2.23.0 | Report a Bug | By Email