Re: [kitten] Kerberos Service Discovery using DNS

Nathaniel McCallum <npmccallum@redhat.com> Wed, 11 March 2015 16:30 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 561CA1ACE38 for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 09:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 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, 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 qzOV9T69idVH for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 09:30:57 -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 74F8B1ACE3D for <kitten@ietf.org>; Wed, 11 Mar 2015 09:30:57 -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 t2BGUuiB024465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Mar 2015 12:30:56 -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 t2BGUqaL011042 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Mar 2015 12:30:54 -0400
Message-ID: <1426091451.3471.35.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Date: Wed, 11 Mar 2015 12:30:51 -0400
In-Reply-To: <alpine.GSO.1.10.1503111201350.3953@multics.mit.edu>
References: <1425578271.2715.5.camel@redhat.com> <alpine.GSO.1.10.1503111201350.3953@multics.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/7JhX9TBgjquWdq4ov7wjg9dnsvU>
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:30:59 -0000

On Wed, 2015-03-11 at 12:05 -0400, Benjamin Kaduk wrote:
> On Thu, 5 Mar 2015, Nathaniel McCallum wrote:
> 
> > I have uploaded a new draft:
> > 
> http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/
> >
> > If you'd like to discuss it, reply to this message. :)
> 
> I'm generally in favor of something like this.
> 
> A few things that came to mind while reading it that have not 
> already been
> raised:
> 
> You cover kerberos and kpasswd, but not kadmin.  Any reason why?  
> (MIT's code does not currently support using DNS to locate an admin 
> server, but that's not a reason to reject adding it to a discovery 
> protocol in its own
> right.)

My understanding is that kadmin is a proprietary protocol and has not 
been standardized. If that is incorrect, I can certainly add it. Does 
it already have a standardized discovery protocol?

> I'm uncertain that section 3 is necessary.  Section 7.2.3.1 of RFC 
> 4120 seems to just be saying "you can't make two kerberos realms 
> that differ only in case"; whatever case is used for the DNS query, 
> the response will
> be the same.

Do I understand you correctly to suggest that I simply remove section 3
altogether and say nothing about realm-to-domain translation?

> 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.

Good point. My justification is simply that the default provided by MS-
KKDCP will confuse DNS admins.

They will see a URI that looks like this:
  https://kdc.foo.com

They will expect this behavior from past experience:
  https://kdc.foo.com/

But they will actually get this behavior:
  https://kdc.foo.com/KdcProxy

Even if we were to use a different URI scheme, I think this behavior 
expectation mismatch will be pronounced.

I suspect the use of /KdcProxy is really just an implementation 
detail. Its only appearance is in Section 2.1 and its meaning is 
rather vague. I would like some clarification from MS regarding this 
question.

Nathaniel