Re: [kitten] Kerberos Service Discovery using DNS

Nathaniel McCallum <npmccallum@redhat.com> Wed, 11 March 2015 16:54 UTC

Return-Path: <npmccallum@redhat.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 553451A1B48 for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 09:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HF-2GFQZitVt for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 09:54:37 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96431A0235 for <kitten@ietf.org>; Wed, 11 Mar 2015 09:54:37 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGsahn012736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Mar 2015 12:54:36 -0400
Received: from unused (unused [10.10.52.96] (may be forged)) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2BGsYr3027162 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Mar 2015 12:54:35 -0400
Message-ID: <1426092874.3471.48.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Date: Wed, 11 Mar 2015 12:54:34 -0400
In-Reply-To: <55006EC9.1030101@mit.edu>
References: <1425578271.2715.5.camel@redhat.com> <alpine.GSO.1.10.1503111201350.3953@multics.mit.edu> <55006EC9.1030101@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/gk8XWc2ykImX9HZjdHv0I9Z2m00>
Cc: kitten@ietf.org
Subject: Re: [kitten] Kerberos Service Discovery using 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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Mar 2015 16:54:39 -0000

On Wed, 2015-03-11 at 12:35 -0400, Greg Hudson wrote:
> On 03/11/2015 12:05 PM, Benjamin Kaduk wrote:
> > Section 5.1 calls out that the default path differs from that in 
> > [MS-KKDCP].  It seems like some justification for this deviation 
> > should be
> > offered, or the gratuitous difference removed.
> 
> Section 2.1 of [MS-KKDCP] states, "The URI uses the virtual 
> directory /KdcProxy unless otherwise configured."  I don't know what 
> this actually means.  I doubt it means that software should convert a
> URI like  http://hostnameto http://hostname/KdcProxy.
> 
> In a similar vein it seems weird for this document to say anything 
> about a default path.  A URI always has a path component; it may be 
> empty.

Perhaps it would be better to say that the path may be empty and that 
the client MUST NOT try to replace an empty path with a default value?

Nathaniel