Re: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00

[Matt Rogers <[e-mail]>]

On Tue, Mar 21, 2017 at 11:54 AM, Greg Hudson <[e-mail]> wrote:
> In general:
>
> * RFC 7553 is informational and this document is standards track, which
>   is a down reference (see RFC 3967).  Also, RFC 7553 contains ambiguous
>   guidance about URI records labels which some readers have interpreted
>   as being incompatible with our use of labels.  I think at one point we
>   received advice to reference the IANA registration of the URI record
>   type instead of RFC; unfortunately I do not know the mechanics of that
>   kind of reference.
>
The IANA registration entry refers to RFC 7553:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
Perhaps it should just be an informative reference instead.

> * Similarly, MS-KKDCP is in the normative references section, and is not
>   a standards-track IETF document.  It is only used as the reference in
>   the initial contents of the transport registry, so perhaps it can just
>   be an informative reference.
>
I'll make this an informative reference.

> Abstract:
>
> * I would rephrase or omit the fourth goal ("define a discovery
>   procedure for Kerberos password services").  There is an
>   interoperable, well-documented[1] de facto standard for discovering
>   kpasswd services; it just isn't specified in an RFC.  It's debatable
>   whether this is a serious enough deficit to mention in the abstract as
>   a problem that we're solving; if it is, I would say "formally specify"
>   rather than "define" to make it clear that the problem being remedied
>   is the lack of a formal specification.

I think "formally specify" would be better.

>
> * Section 4.2.1 (Master Flag) is too focused on password changes, I
>   think.  I suggest:
>
>   The client SHOULD consider this server as one that might possess more
>   up-to-date long-term key material, and use it as a fallback for errors
>   that might result from out-of-date keys.
>
Works for me.

> Section 4.4 (Residual):
>
> * I suggest "where such are defined" -> "as defined"
>

This will be removed with the Residual section (based on past comments
to redefine the fields as
"krb5srv:[flags]:transport-type:transport-info")

> Section 5 (Kerberos V5 KDC Service Discovery):
>
> * "REALM indicates the translation of the Kerberos realm to a DNS
>    domain" seems to invoke some kind of translation procedure without a
>    reference.  RFC 4120 doesn't really define any such translation
>    procedure; it just says in section 6.1 that a realm might be in
>    domain style with some specifics on what that means, and in section
>    7.2.3.2 that "The realm MUST be a domain-style realm name".
>
>    (Section 6 has this same wording again.)

How about "..client MUST query the following URI DNS record, where
REALM is a domain-style realm name."

>
> Section 7 (Kerberos Admin Service Discovery):
>
> * There is no standard admin protocol, even a de facto one (well,
>   Heimdal has some interoperability with MIT krb5).  It doesn't make a
>   lot of sense to specify a standard discovery protocol when there is no
>   standard for what is being discovered.  I think we want to leave this
>   as an implementation-specific aside.
>
>   This change would have an impact on section 9.2.1 (removing the
>   default admin service port) and 9.2.2.
>
I'm OK with removing this part.

> Section 8 (Relationship to Existing Mechanism):
>
> * The wording here seems too general.  I think we want to specifically
>   say that URI records should be preferred over SRV records.
>

How about: "Clients that support service discovery through both URI
and SRV records SHOULD perform the URI discovery first. If no URI
record is found, the client MAY then attempt SRV discovery."

> Section 9.1.2 (Initial Registry Contents, for flags registry):
>
> * The reference here is "TBD".  Is there a plan?  Is the reference
>   supposed to be to this RFC once a number is assigned?
>

It should be changed to the assigned number, yes. It was suggested
that instead of TBD we use [This Document], which I think is the
convention for this kind of reference.

I'd also like to get some thoughts on this text for a Security
Considerations section:
"The security implication of using DNS URI records is identical to
that of using DNS for any Kerberos service or host mapping; without
secure DNS the results can be forged.  The same precautions regarding
the use of insecure DNS with Kerberos outlined in RFC 4120 should be
followed."

Thanks,
Matt