Re: [kitten] New URI Discovery Draft

[Petr Spacek <[e-mail]>]

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.


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