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

Nico Williams <nico@cryptonector.com> Tue, 15 September 2015 19:52 UTC

Return-Path: <nico@cryptonector.com>
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 217371ACDE9 for <kitten@ietfa.amsl.com>; Tue, 15 Sep 2015 12:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level:
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 8fnUk4n5HPdF for <kitten@ietfa.amsl.com>; Tue, 15 Sep 2015 12:52:19 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C2E681ACDE3 for <kitten@ietf.org>; Tue, 15 Sep 2015 12:52:18 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 2F3E42AC0A4; Tue, 15 Sep 2015 12:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=wQf+X8NJSUcw8jkzIYQbOdumFJo =; b=kC/IWjmDAjhgjJes/ikYmE9BXw1+3+gkTEbTuQoqFQnwS7XHdzT25MdIxpN /JLyXF3EU3gJDru/9mf9HXipGn5FRuoHbBMDbq7Zf2S7X6A3/EWOt27DTFoOezrC Ao5bMeo/itG1XPFhbYGYGRNysmSC4cp9cQ5QhhmGwBxpV4OM=
Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id D1BBD2AC073; Tue, 15 Sep 2015 12:52:17 -0700 (PDT)
Date: Tue, 15 Sep 2015 14:52:17 -0500
From: Nico Williams <nico@cryptonector.com>
To: kitten@ietf.org
Message-ID: <20150915195215.GJ13294@localhost>
References: <55F686EA.30206@openfortress.nl> <55F6EA7C.8070608@mit.edu> <20150914161100.GC13294@localhost> <55F6F843.2070609@openfortress.nl> <20150914170757.GC13284@localhost> <55F72B14.8030409@openfortress.nl> <55F7C40F.9000509@openfortress.nl> <55F86534.50109@mit.edu> <20150915190036.GV21942@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20150915190036.GV21942@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/7KkPK0NXodrVnSz7e6RNg3d4fs8>
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: Tue, 15 Sep 2015 19:52:20 -0000

On Tue, Sep 15, 2015 at 07:00:36PM +0000, Viktor Dukhovni wrote:
> I for one don't see any reason to support multiple realms in the
> response.

Some services have the same name in multiple realms...  If there's a
more preferred transit path (or not every path is available) then in
principle a client (or referral issuer) might need to know about the
service's multiple realms.  A KDC issuing referrals can certainly pick
the better realm based on the transit path that will be required (though
this need not be the optimal path from the service's point of view) to
reach it given the capaths information available to the KDC.

So multiple PTR RRs can be meaningfully supported, but I agree that by
and large only one should be published, and that supporting more than
one will impose a significant additional burden for implementors.

Nico
--