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
- Re: [kitten] Kerberos Service Discovery using DNS Petr Spacek
- Re: [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Greg Hudson
- Re: [kitten] Kerberos Service Discovery using DNS Petr Spacek
- [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Greg Hudson
- Re: [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Simo Sorce
- Re: [kitten] Kerberos Service Discovery using DNS Nico Williams
- Re: [kitten] Kerberos Service Discovery using DNS Rick van Rein
- Re: [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Rick van Rein
- Re: [kitten] Kerberos Service Discovery using DNS Greg Hudson
- Re: [kitten] Kerberos Service Discovery using DNS Rick van Rein
- Re: [kitten] Kerberos Service Discovery using DNS Viktor Dukhovni
- Re: [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Benjamin Kaduk
- Re: [kitten] Kerberos Service Discovery using DNS Benjamin Kaduk
- Re: [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Greg Hudson
- Re: [kitten] Kerberos Service Discovery using DNS Benjamin Kaduk
- Re: [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Nathaniel McCallum
- Re: [kitten] Kerberos Service Discovery using DNS Jeffrey Altman