Re: [kitten] Fwd: New Version Notification for draft-vanrein-dnstxt-krb1-05.txt

Rick van Rein <rick@openfortress.nl> Fri, 18 September 2015 17:30 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 5F31B1B2ABF for <kitten@ietfa.amsl.com>; Fri, 18 Sep 2015 10:30:37 -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 41xEyCdumsNs for <kitten@ietfa.amsl.com>; Fri, 18 Sep 2015 10:30:35 -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 39A3E1B2A72 for <kitten@ietf.org>; Fri, 18 Sep 2015 10:30:34 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id JhWX1r00E10HQrX01hWYlT; Fri, 18 Sep 2015 19:30:32 +0200
Message-ID: <55FC4A37.9020305@openfortress.nl>
Date: Fri, 18 Sep 2015 19:30:31 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: kitten@ietf.org
References: <20150915143628.21162.89108.idtracker@ietfa.amsl.com> <55F82DA5.10504@openfortress.nl> <alpine.GSO.1.10.1509172254390.26829@multics.mit.edu> <55FBF0C8.6090904@openfortress.nl> <20150918140247.GB13294@localhost> <20150918153219.GP21942@mournblade.imrryr.org>
In-Reply-To: <20150918153219.GP21942@mournblade.imrryr.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/WxUp3DDQ4L10JdSkqygMGcWdH0I>
Subject: Re: [kitten] Fwd: New Version Notification for draft-vanrein-dnstxt-krb1-05.txt
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: Fri, 18 Sep 2015 17:30:37 -0000

Hi,
>> I'm very reluctant to agree to that, but I'd agree to saying that a TGS
>> client should first try the realm as it appears in the PTR RR and then
>> as up-cased if the first failed.
>
> What does it mean to "try the realm"?

In all but the local-realm case, the client may need its KDC to learn
about the proper case for the service's realm name.  But, as you've
shown, the KDC should now if the client doesn't.
> The only time that determining the canonical form of the remote
> realm becomes plausibly difficult, is when trust is constructed on
> the fly via public keys in DNSSEC.  When such a protocol is designed,
> the canonical realm suffix can be communicated as part of the
> authenticated cross-realm key exchange.

The ways for doing this that Nico and I are brooding on, are based on
PKINIT, and use certificates that hold the realm name in its proper
case.  DNSSEC/DANE in turn can validate those certificates.  So even in
that case the mapping to a known case is possible.

-Rick