Re: [kitten] Kerberos Service Discovery using DNS

Simo Sorce <simo@redhat.com> Fri, 06 March 2015 22:58 UTC

Return-Path: <simo@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 5D3FE1A6F33 for <kitten@ietfa.amsl.com>; Fri, 6 Mar 2015 14:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oBeiYiV77Jkm for <kitten@ietfa.amsl.com>; Fri, 6 Mar 2015 14:58:51 -0800 (PST)
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 836FD1A1BC6 for <kitten@ietf.org>; Fri, 6 Mar 2015 14:58:51 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t26MwoQW030353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 6 Mar 2015 17:58:50 -0500
Received: from [10.3.113.41] (ovpn-113-41.phx2.redhat.com [10.3.113.41]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t26Mwn3Y004935; Fri, 6 Mar 2015 17:58:50 -0500
Message-ID: <1425682729.2889.24.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Date: Fri, 06 Mar 2015 17:58:49 -0500
In-Reply-To: <54FA1F7D.2050703@mit.edu>
References: <1425578271.2715.5.camel@redhat.com> <54FA1F7D.2050703@mit.edu>
Organization: Red Hat, Inc.
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.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/53V3ucznbahekCpfAUtdJm583jg>
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: Fri, 06 Mar 2015 22:58:53 -0000

On Fri, 2015-03-06 at 16:43 -0500, Greg Hudson wrote:
> On 03/05/2015 12:57 PM, Nathaniel McCallum wrote:
> > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/
> 
> I'm on board with this in general. 

I like it too.

>  Some specific issues to be hashed out:
> 
> 1. URL formats for basic RFC 4120 over UDP/TCP
> 
> The draft uses udp://hostname[:port] and tcp://hostname[:port] for
> these.  The IANA registry notes some application-specific precedent for
> the use of a "udp" scheme but there is no formal spec for it, and there
> is no registration for "tcp" at all.  Obviously these URI schemes are
> very context-dependent; a generic application such as a web browser
> would have no idea what to do with a TCP or UDP URL.  On the other hand,
> we are also proposing a very context-specific use of HTTP for MS-KKDCP,
> and there is a ton of precedent for that (basically any kind of RPC over
> HTTP).
> 
> 2. UDP/TCP preference
> 
> Some implementation guidance may be necessary on this.  Implementations
> are currently used to having their own preference of UDP versus TCP,
> perhaps based on the packet size.
> 
> The current draft does allow the URI records to express no preference of
> UDP versus TCP; one can simply give them the same priority and don't use
> weights.  But if the URI records express a preference, should a client
> always honor that preference, or can it ignore it--say, if the packet is
> large?

I think the client SHOULD use the URI order in preference, but MAY
override it if it knows that the packet size will make it impossible to
use the URI preferred method. (Ie if the URI makes UDP preferred but the
client knows the size for the specific exchange is going to be too large
for UDP, it may decide to do straight TCP/MS-KKDCP instead).

> 3. Precedence of URI versus SRV
> 
> Discussion elsewhere suggested that the URI records, if present, should
> have precedence over SRV records; if a client finds URI records, it
> shouldn't do SRV lookups.  The draft should probably say that explicitly.

+1

> 4. Security considerations
> 
> MS-KKDCP can offer security benefits for Kerberos traffic because it
> uses TLS.  These added protections are mostly lost if unsecured URI
> records are used to discover the proxy URL.  This is not a deal-breaker
> as there are other reasons to use a proxy, but we should explicitly
> state this in the security considerations.

True, but DNSSEC may help in this case, so it is not that weak, should
be pointed out anyway.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York