Re: [kitten] Kerberos Service Discovery using DNS

Nathaniel McCallum <npmccallum@redhat.com> Wed, 11 March 2015 15:26 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 468371A8883 for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 08:26:21 -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 F11VOFOi8Gfv for <kitten@ietfa.amsl.com>; Wed, 11 Mar 2015 08:26:20 -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 36DC51A8878 for <kitten@ietf.org>; Wed, 11 Mar 2015 08:26:20 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BFQIbk028368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Mar 2015 11:26:19 -0400
Received: from unused (unused [10.10.52.96] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2BFQHOh014470 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Mar 2015 11:26:17 -0400
Message-ID: <1426087576.3471.19.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Rick van Rein <rick@openfortress.nl>
Date: Wed, 11 Mar 2015 11:26:16 -0400
In-Reply-To: <C8C3D9F0-5D74-493C-A75A-60AD5B765662@openfortress.nl>
References: <1425578271.2715.5.camel@redhat.com> <2CB0CE49-2109-4666-9FFA-33538244E84E@openfortress.nl> <1426025143.16339.10.camel@redhat.com> <C8C3D9F0-5D74-493C-A75A-60AD5B765662@openfortress.nl>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/oN--Emgdy2SHa8Zi4J9NHL4lHKI>
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 15:26:21 -0000

On Wed, 2015-03-11 at 10:25 +0100, Rick van Rein wrote:
> > > Please do not overlool SCTP; it has the reliability and size- 
> > > scalability of TCP but the speed and ordering advantages of UDP. 
> > >   Even when Kerberos does not currently use SCTP, it may need to 
> > > in  future updates, possibly to handle large key sizes during 
> > > PKINIT.
> > 
> > Since there is not currently an SCTP protocol defined, we cannot 
> > write  a method for discovering it. Feel free to work on one. :)
> 
> Hmm, yes this chicken-and-egg problem is everywhere where new
> protocols are introduced, and it is generally considered valid 
> reasoning.
> I won’t press this hard, but think it leads to an impasse, which is 
> why I mentioned it; you are very specific about UDP and TCP and so 
> you are explicitly passing by SCTP.

This isn't a chicken-and-egg problem. There is a dependency, but it is 
not circular.

Future transports and services will define new URI formats and 
prefixes, respectively, in their own RFCs. The scope of this draft is 
to define:
1. an extensible discovery protocol
2. prefixes for pre-existing services
3. URI formats for pre-existing transports

In short, don't feel like we have to cram SCTP into this draft. As I 
mentioned before, please feel free to write up an SCTP draft. It can 
define a URI format and reference this draft as a normative reference.

Nathaniel