Re: [kitten] New URI Discovery Draft
Nathaniel McCallum <npmccallum@redhat.com> Mon, 26 September 2016 17:10 UTC
Return-Path: <npmccallum@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B06912B316 for <kitten@ietfa.amsl.com>; Mon, 26 Sep 2016 10:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.217
X-Spam-Level:
X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6kVPaIc_DMYY for <kitten@ietfa.amsl.com>; Mon, 26 Sep 2016 10:10:13 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABDD12B312 for <kitten@ietf.org>; Mon, 26 Sep 2016 10:10:13 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CA51E67AF1 for <kitten@ietf.org>; Mon, 26 Sep 2016 17:10:12 +0000 (UTC)
Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8QHA1Q4011901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Sep 2016 13:10:12 -0400
Message-ID: <1474909801.27445.4.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Petr Spacek <pspacek@redhat.com>, kitten@ietf.org
Date: Mon, 26 Sep 2016 13:10:01 -0400
In-Reply-To: <c2e61e27-8a6c-1d38-140e-0c019b0a13a2@redhat.com>
References: <1474669521.30344.15.camel@redhat.com> <c2e61e27-8a6c-1d38-140e-0c019b0a13a2@redhat.com>
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
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 26 Sep 2016 17:10:12 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/VM97bXsxaEs0ZvCCqvOrqLUVwGk>
Cc: Matt Rogers <mrogers@redhat.com>, Simo Sorce <simo@redhat.com>
Subject: Re: [kitten] New URI Discovery Draft
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 26 Sep 2016 17:10:15 -0000
On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote: > On 24.9.2016 00:25, Nathaniel McCallum wrote: > > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service- > > disc > > overy/ > > > > I've submitted a new version of the draft. This version matches the > > code that is now merged into MIT Kerberos. > > > > We need to move forward. If that is as an individual submission, > > then > > so be it. But we really can't wait any longer. So unless I hear > > some > > noise to the contrary ASAP, I plan to go this route. > > > Hello, > > in general it makes sense. The new URI format opened an encoding- > Pandora-box > so it needs more work to make it fully specified. Here are nits I > found in the > 03 version of the draft: > > 1] > > 4. Required URI Format > > krb5srv:[flags]:transport:residual > > Nitpick: I do not really like naming "transport:residual". Something > like > "transport-type:transport-options" would be more descriptive. > > > 2] Is this a good idea? > > Flags are not considered critical, therefore flags that are not > > used > > or unknown to the implementation SHOULD be ignored. > > Just wondering out loud, not insisting on it: > If we say there is no criticality, it will be impossible to add later > on. > > What about using capitalization to indicate criticality of a flag? > Records > with critical but unsupported flags should be skipped as if there > were not > present in DNS. Records with non-critical unsupported flags should be > used as > usual. > > Or maybe we can limit valid flags to lowercase ASCII letters for now > so there > is a room for extension in future? > > > 3] In any case, there is disagreement between > > 4.2. Flags > > This field contains a sequence of zero or more case-insensitive > > vs. > > 9.1. Kerberos Server Discovery Flags > > 9.1.1. Registration Template > > Value: A single unique ASCII character that identifies the > > entry, > > > "A single unique ASCII character" is case-sensitive by definition. > This > conflicts with case-insensitivity defined in 4.2. There is actually a bigger issue here which is that referring to it as "ASCII character" is too broad. What we really want here are the letters a-z. > 3] The draft is not clear on whether transport field is case- > sensitive or not. > > 4.3. Transport > > 9.2. Kerberos Server Discovery Transport Types > > > > 4] Residual formats are not sufficiently specified: > > 4.4. Residual > > 9.2. Kerberos Server Discovery Transport Types > > 9.2.2. Initial Registry Contents > > > > o Value: "udp" > > o Description: User Datagram Protocol > > o Residual Format: "host[:port]" > > o Case Sensitive: None > > o Default KDC Port: 88 > > o Default Admin Service Port: 749 > > o Default Password Service Port: 464 > > o Reference: [RFC0768] > > > There is no definition of "host" and there is none in RFC 768. > Can it be IP(v?) address? > Can it be DNS name? > How this field should be encoded into the URI? > > > o Value: "tcp" > > o Description: Transport Control Protocol > > o Residual Format: "host[:port]" > > o Case Sensitive: None > > o Default KDC Port: 88 > > o Default Admin Service Port: 749 > > o Default Password Service Port: 464 > > o Reference: [RFC0793] > > > Again there is no definition of "host". > Can it be IP(v?) address? > Can it be DNS name? > How this field should be encoded into the URI? > > > o Value: "kkdcp" > > o Description: Kerberos Key Distribution Center Proxy Protocol > > o Residual Format: https://host[:port][/path] > > > This is technically URI inside URI, am I right? > How is it encoded? Should usual %-encoding be used here? > > 10.1. URI Format Examples > > suggest that %-encoding is not used. I would like to see this clearly > specified and explained why not. > > At this point I would rather say "use URL as specified by [MS-KKDCP]" > instead > of specifying "https://host[:port][/path]". > > Also, to make this bullet-proof, I would mention that "/KdcProxy" > must be > explicitly specified in the URI record and is not implicitly assumed > by clients. > > > o Case Sensitive: [/path] > > o Default KDC Port: 443 > > o Default Admin Service Port: 443 > > o Default Password Service Port: 443 > > o Reference: [MS-KKDCP] > > > > Other than that it makes sense and I'm looking forward to see this > deployed! > >
- [kitten] New URI Discovery Draft Nathaniel McCallum
- Re: [kitten] New URI Discovery Draft Petr Spacek
- Re: [kitten] New URI Discovery Draft Greg Hudson
- Re: [kitten] New URI Discovery Draft Matt Rogers
- Re: [kitten] New URI Discovery Draft Petr Spacek
- Re: [kitten] New URI Discovery Draft Matt Rogers
- Re: [kitten] New URI Discovery Draft Nathaniel McCallum
- Re: [kitten] New URI Discovery Draft Nathaniel McCallum
- Re: [kitten] New URI Discovery Draft Greg Hudson
- Re: [kitten] New URI Discovery Draft Benjamin Kaduk
- Re: [kitten] New URI Discovery Draft Benjamin Kaduk
- Re: [kitten] New URI Discovery Draft Matt Rogers