Re: [kitten] New URI Discovery Draft

[Matt Rogers <[e-mail]>]

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

Hi Petr, thanks for reviewing! 

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

"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"?

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

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.

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

I'll clear this up.

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

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

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

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.

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

Sure, that makes sense. 

Thanks again,
Matt