Subject: [kitten] New URI Discovery Draft

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 23 Sep 2016 18:25:21 -0400

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.

Nathaniel

---

From: Petr Spacek <[email-masked]>
Date: Sat, 24 Sep 2016 18:29:55 +0200

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

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!

-- 
Petr^2 Spacek

---

From: Greg Hudson <[email-masked]>
Date: Mon, 26 Sep 2016 11:21:14 -0400

> If we say there is no criticality, it will be impossible to add later on.

I think that's fine.  Let's not over-engineer this.

> What about using capitalization to indicate criticality of a flag?

It's definitely not worth introducing case-sensitivity to an otherwise
case-insensitive DNS value format.

> is a room for extension in future?

Criticality cannot be introduced later as an extension.  But again, I
don't think we need to engineer critical flags into this spec.  Flags
are only barely necessary at all.

> How this field should be encoded into the URI?

Per the implementation, it can be a DNS hostname, and IPv4 address, or
an IPv6 address enclosed in square brackets.

> How is it encoded? Should usual %-encoding be used here?

% encoding is not used.  Formally, you can imagine the https URI syntax
being incorporated into the syntax of the krb5srv part.  I'm not sure
how best to express that in the document.

---

From: Matt Rogers <[email-masked]>
Date: Mon, 26 Sep 2016 11:55:18 -0400

> so it needs more work to make it fully specified. Here are nits I

Hi Petr, thanks for reviewing! 

> "transport-type:transport-options" would be more descriptive.

"transport-options" may make it seem that it's an optional field or
carries something other than a hostname or URI for the client to
contact. How about "transport-type:transport-target"?

> Records

I think avoiding having case-sensitive fields is the most appropriate
thing to do for DNS data, our exception here being the path part of a
KKDCP URL, which we can leave as defined by MS-KKDCP (see below)

If we want to later add criticality to a flag then it could be a flag
prepended by a '!' or some such character rather than using the case.

> > 9.2.  Kerberos Server Discovery Transport Types

I'll clear this up.

> How this field should be encoded into the URI?

Good point, I'll clear this up as well.

> of specifying "https://host[:port][/path]".

I agree with this, especially since MS-KKDCP defines the URI with
RFC3986 encoding rules. I think then the registration template can also
leave out the case-sensitivity definition as the path is defined as
case-sensitive with RFC3986.

> explicitly specified in the URI record and is not implicitly assumed

Sure, that makes sense. 

Thanks again,
Matt

---

From: Petr Spacek <[email-masked]>
Date: Mon, 26 Sep 2016 18:01:00 +0200

> contact. How about "transport-type:transport-target"?

Sounds good.

> prepended by a '!' or some such character rather than using the case.

Fine with me. The main point is that if we do not define criticality or at
least reserved character now it will be impossible to enforce it on older
clients. Maybe we can reserve "!" character now and say that character
immediately following "!" must be ignored by clients implementing this version
of the draft?

>> explicitly specified in the URI record and is not implicitly assumed
I'm happy to review it again.

-- 
Petr^2 Spacek

---

From: Matt Rogers <[email-masked]>
Date: Mon, 26 Sep 2016 13:02:27 -0400

> immediately following "!" must be ignored by clients implementing

I'm thinking that the flag should not be ignored, but just that in this
version of the draft '!' is reserved but ignored and no criticality is
assumed on the following flag. In a future version the '!' could
indicate that the following flag is critical.

Regards,
Matt

---

From: Nathaniel McCallum <[email-masked]>
Date: Mon, 26 Sep 2016 13:10:01 -0400

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

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 28 Sep 2016 12:07:39 -0400

> "transport-type:transport-options" would be more descriptive.

transport-info? transport-data? transport-spec?

> is a room for extension in future?

I had proposed using case for criticality in another conversation and
I'm increasingly coming to prefer this method if criticality is defined
as "don't use this server if you don't understand the flag."

Note that with either case-insensitivity or critical-uppercase we have
the same number of letters. So I don't think there is any cost except
the (minor) cost of updating the exiting MIT code.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 28 Sep 2016 12:50:33 -0400

> transport-info? transport-data? transport-spec?

I like transport-info.

> as "don't use this server if you don't understand the flag."

My opinion hasn't changed; I still think we have no need for critical
flags, and don't want to add complexity.

(It's very normal to define an extensible protocol field with no support
for critical values.  padata and ticket flags are two examples that come
to mind.)

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 29 Sep 2016 23:29:46 -0400 (EDT)

> noise to the contrary ASAP, I plan to go this route.

The chairs talked about this, and it seems like we've made enough progress
getting WG consensus on documents [that are now blocking on shepherd
writeups] that we're probably in a state where accepting new WG documents
can happen fairly soon.  That said, we'd really like to get some more
review on draft-ietf-kitten-rfc5653bis-03 so that can move forward as
well.  Any chance you'll be able to provide a review?

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 29 Sep 2016 23:53:31 -0400 (EDT)

> code that is now merged into MIT Kerberos.

A few comments (with no particular hat):

Section 4.2.1, "master server" is only implicitly defined; would it be
reasonable to say that such are "expected to be an authoritative source
for KDC database information, not subject to propagation delay"?

It's probably worth a forward reference to the IANA considerations
somewhere in Section 4.2 to note how new flags can be allocated.  Likewise
for the transport types in 4.3 (as well as a list of the types specified
by this document!).

I'd be slightly tempted to reorder things so section 4 comes after
sections 5, 6, and 7 (so that the queries come first and the field
contents later), but that's really a stylistic question and subject to
authorial discretion.

Sections 5, 6, and 7 say "[t]arget SHOULD contain one of the URI formats
specified in this document", but doesn't this document only contain one
(required) URI format?

Section 7 should probably note that the kadmin protocol is not
standardized and consumers must be aware of the server implementation.
(If we're really excited, we could even include a field to indicate what
the server implementation is, but that would run the risk of introducing
IETF politics at IETF LC or IESG review.)

I don't believe that the kitten list can be a designated expert (and it's
unclear what exactly the document is saying will be done for expert
review).  IIRC, the necessary things in this part are to give the IESG
guidance for selecting Designated Expert(s) (e.g., well-known kerberos
implementors, past or current krb-wg/kitten chairs, etc.), as well as
instructions for what review/criteria the expert should apply when
considering registration requests.  Requiring the expert to call for open
discussion on the kitten list can be part of the instructions to the
expert, but probably ought not be the entirety of those instructions.
Also, it's my understanding that IANA likes things to be written in the
form "IANA has done $X", though for drafts, people tend to write "IANA
[will do|has done]" with literal brackets and pipe.

We already covered the non-case-sensitivity of the flags, but as a nit,
the reference field should be to a document that describes the details of
the flag.  I don't see how the reference for the 'm' flag would not be
"[this document]".

The examples would be more useful if accompanied by prose description of
what they mean.

-Ben

---

From: Matt Rogers <[email-masked]>
Date: Fri, 30 Sep 2016 15:38:19 -0400

On Thu, 2016-09-29 at 23:53 -0400, Benjamin Kaduk wrote:

Thanks for the review!

> for KDC database information, not subject to propagation delay"?

With this re-wording would it be more appropriate to specify in the
IANA definition for 'm' and not under 4.2?

> for the transport types in 4.3 (as well as a list of the types

Ack.

> contents later), but that's really a stylistic question and subject

Not a bad suggestion for the overall flow of the document.

> specified in this document", but doesn't this document only contain

Yes, that's left over from a previous revision, so I'll correct that.

> [will do|has done]" with literal brackets and pipe.

Ok, I'll work on revising this.

> the flag.  I don't see how the reference for the 'm' flag would not
I'll update this reference. Also, after some further discussion about
the case-sensitivity and flag criticality issue, I think ultimately the
right thing to do for this version of the draft is to just specify that
the URI fields are case-sensitive and unknown flags must be ignored. A
registered transport can then maintain any case-sensitive elements
(such as the path extension for KKDCP) while the scheme, flags, and
transport names will be registered with their literal values so there
should not be any ambiguity on the case for those fields. 

If later on a critical flag needs to be added, then this would leave it
open to being a capital version of an existing flag or just a different
character altogether.

> The examples would be more useful if accompanied by prose description

Good point. 

Thanks again,
Matt